Client/Server application with single login-SecureStream?

16 Jan 2006 2:01 PM

cmbardon

I have a client/server application that uses TCP socket based
communication, and right now I'm using my own ID/password scheme.
Clients send an ID and password to the server, which authenticates them
against a table in a local SQL database. This requires users to keep
track of multiple logins/passwords though, so I'm looking at how I can
take advantage of their domain login to avoid having to have two sets
of credentials.

Associating the user accounts on my server applicaiton with the domain
accounts is not a problem, but authenticating the original connection
is. When my client opens a socket to my server, I can have it provide
the currently logged in user name, but this can be very easily spoofed.
I want to be able to ensure that when my client opens a socket to my
server, that the domain user name it sends cannot be spoofed-i.e. that
the machine the socket is being opened from has actually been
authenticated against the domain with the specified username.

I've started looking at the SecureStream class and Kerberos
authentication, and this appears that it'll do what I want. I've run
into two problems so far though. First, I tried the sample code in
MSDN on a few different platforms (server 03, 2000, and XP pro), and in
none of these cases could I get a connection with Kerberos
wuthentication-only NTLM. The docs say that kerberos is used unless
its unavailable, and that NTLM is only a fallback, but Kerberos should
be configured on server 2003 by default, right? There's also the added
complication that the client and server will not necessarily be on the
same domain-which so far seems to mean that SecureStream will not be
able to authenticate the client. Will Kerberos get around this
problem?

Am I at least on the right track here, or is there a better way to do
this type of authentication for TCP based client/server apps? I've
seen a lot of posts talking about solutions for ASP.net apps, but very
few dealing with standalone client/server.

Thanks for your help everyone!

16 Jan 2006 3:20 PM

Dominick Baier [DevelopMentor]

Hi,

NegotiateStream is the way to go.

If your multiple domains have a trust relationship you can use kerberos -
no problem.

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

Show quoteHide quote

> I have a client/server application that uses TCP socket based
> communication, and right now I'm using my own ID/password scheme.
> Clients send an ID and password to the server, which authenticates
> them against a table in a local SQL database. This requires users to
> keep track of multiple logins/passwords though, so I'm looking at how
> I can take advantage of their domain login to avoid having to have two
> sets of credentials.
>
> Associating the user accounts on my server applicaiton with the domain
> accounts is not a problem, but authenticating the original connection
> is. When my client opens a socket to my server, I can have it provide
> the currently logged in user name, but this can be very easily
> spoofed.
> I want to be able to ensure that when my client opens a socket to my
> server, that the domain user name it sends cannot be spoofed-i.e. that
> the machine the socket is being opened from has actually been
> authenticated against the domain with the specified username.
>
> I've started looking at the SecureStream class and Kerberos
> authentication, and this appears that it'll do what I want. I've run
> into two problems so far though. First, I tried the sample code in
> MSDN on a few different platforms (server 03, 2000, and XP pro), and
> in none of these cases could I get a connection with Kerberos
> wuthentication-only NTLM. The docs say that kerberos is used unless
> its unavailable, and that NTLM is only a fallback, but Kerberos should
> be configured on server 2003 by default, right? There's also the
> added complication that the client and server will not necessarily be
> on the same domain-which so far seems to mean that SecureStream will
> not be able to authenticate the client. Will Kerberos get around this
> problem?
>
> Am I at least on the right track here, or is there a better way to do
> this type of authentication for TCP based client/server apps? I've
> seen a lot of posts talking about solutions for ASP.net apps, but very
> few dealing with standalone client/server.
>
> Thanks for your help everyone!
>

16 Jan 2006 3:33 PM

cmbardon

Dominic, thanks for the quick reply. Glad to know that I'm at least on
the right track. I actually saw the sample on your site as well, and
noticed that when I used your code instead of the MSDN, I still only
got NTLM authentication. Is there something I have to do on the server
side to establish a valid SPN, or can I fill in whatever I want on the
client? The server will run on a server 2003 machine, and I've seen a
"setspn" tool referenced that doesn't seem to exist. Is there a way
for my .net application to create an SPN on startup?

Also, what will happen if the client machine is a member of domain A,
but the server machine is not joined to a domain at all. Should
kerberos work in this situation, or is it dependent on the domain
controller?

Thanks!

Chris

16 Jan 2006 3:41 PM

Dominick Baier [DevelopMentor]

Hi,

kerberos will only work with domain accounts.

the spn is the account the server runs under, e.g. domain\serveraccount.
A SPN allows you to establish a symbolic name for that account, e.g. serviceX/domain
- whithout having to hard code the server account name.

SetSPN is included on the windows server 2003 cd in the support tools folder.

You need domain admins privs to create a SPN.

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

Show quoteHide quote

> Dominic, thanks for the quick reply. Glad to know that I'm at least
> on the right track. I actually saw the sample on your site as well,
> and noticed that when I used your code instead of the MSDN, I still
> only got NTLM authentication. Is there something I have to do on the
> server side to establish a valid SPN, or can I fill in whatever I want
> on the client? The server will run on a server 2003 machine, and I've
> seen a "setspn" tool referenced that doesn't seem to exist. Is there
> a way for my .net application to create an SPN on startup?
>
> Also, what will happen if the client machine is a member of domain A,
> but the server machine is not joined to a domain at all. Should
> kerberos work in this situation, or is it dependent on the domain
> controller?
>
> Thanks!
>
> Chris
>

18 Jan 2006 12:41 PM

cmbardon

If kerberos will only work with domain accounts, then would it be
possible to use NegotiateStream to authenticate a client on a server
that is NOT a member of a domain? You said that Kerberos will only
work on machines that belong to the same domain, or to domains that
trust each other, but I'm looking at a case where client A is a member
of domain D, and server B is connected to the same network as A, but is
not a member of any domains (just a windows server box configured on a
workgroup). Will B still be able to authenticate the client if it
opens a secureStream connection? In other words, if B is not a member
of the domain, can it still contact the domain controller to
authenticate?

18 Jan 2006 3:49 PM

Joe Kaplan (MVP - ADSI)

NegotiateStream uses the negotiate protocol which uses Kerberos or NTLM.
NTLM can authenticate local machine accounts, so it should be possible to
use it with the workgroup server as well.

Joe K.

<cmbar***@engmail.uwaterloo.ca> wrote in message
Show quoteHide quote

news:1137588070.842925.291890@g14g2000cwa.googlegroups.com...
> If kerberos will only work with domain accounts, then would it be
> possible to use NegotiateStream to authenticate a client on a server
> that is NOT a member of a domain? You said that Kerberos will only
> work on machines that belong to the same domain, or to domains that
> trust each other, but I'm looking at a case where client A is a member
> of domain D, and server B is connected to the same network as A, but is
> not a member of any domains (just a windows server box configured on a
> workgroup). Will B still be able to authenticate the client if it
> opens a secureStream connection? In other words, if B is not a member
> of the domain, can it still contact the domain controller to
> authenticate?
>

18 Jan 2006 6:22 PM

Dominick Baier [DevelopMentor]

Hi,

NegotiateStream will fallback to a protocol called NTLM to do non-Domain
based authentication, you need

a) mirrored accounts on both machines or
b) specifiy credentials to use

http://www.leastprivilege.com/NegotiateStreamAndNTLM.aspx

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

Show quoteHide quote

> If kerberos will only work with domain accounts, then would it be
> possible to use NegotiateStream to authenticate a client on a server
> that is NOT a member of a domain? You said that Kerberos will only
> work on machines that belong to the same domain, or to domains that
> trust each other, but I'm looking at a case where client A is a member
> of domain D, and server B is connected to the same network as A, but
> is not a member of any domains (just a windows server box configured
> on a workgroup). Will B still be able to authenticate the client if
> it opens a secureStream connection? In other words, if B is not a
> member of the domain, can it still contact the domain controller to
> authenticate?
>