NTLM authentication

[Willy Denoyette [MVP]]

Re: NTLM authentication

"webrod" <rodolphe.aoust in@gmail.comwro te in message
news:1167909149 .759083.317590@ 6g2000cwy.googl egroups.com...

>

I forgot to answer to your question.
I can't use kerberos because I am on a Winnt system based on NTML not
kerberos.

>>
>I don't get it, this is a local intranet and you are only running SQL on a server which
>is
>not a Domain member and you want to authenticate windows (local )accounts using NTLM
>(that
>is SQL integrated security)?

>
SQL? Why are we speaking about SQL? :)
>

Sorry got confusd by the NTLM database ;-)

Actually, I have users who belong to a domain (WinNT).
So I have users in the SAM database.

Yep, NT4 Domains shiver.

Now what I want is to check that a user really exists in this DB with a
.NET script.
So I would like a way to query the SAM database OR to bind the SAM
database.
>

Don't consider the SAM a dtabase you can access, it's part of the NT security system and
actualy it's the security system (LSA)that performs the check by authenticating, just like
IIS is doing.

>Well, I'm afraid the answer is - you can't use WSE 3.0 without IIS hosting for this.

>
Yes, IIS is hosting my Web Service (the WS has to check the user
credential to provide access to the WS or not).
I am not saying that IIS is not hosting my WS, I am just saying that I
would like to have a solution without using IIS settings.
>

IIS has everything in place to authenticate (provided it is correctly configured) a user
account using NTLM, something WSE is lacking.

Willy.

Willy.

[Willy Denoyette [MVP]]

Re: NTLM authentication

"Mark Rae" <mark@markNOSPA Mrae.comwrote in message
news:%23KJnvM$L HHA.3952@TK2MSF TNGP02.phx.gbl. ..

"webrod" <rodolphe.aoust in@gmail.comwro te in message
news:1167909149 .759083.317590@ 6g2000cwy.googl egroups.com...
>

>Actually, I have users who belong to a domain (WinNT).
>So I have users in the SAM database.
>Now what I want is to check that a user really exists in this DB with a
>.NET script.
>So I would like a way to query the SAM database OR to bind the SAM
>database.

>
Is *that* all you want to do...? I.e. validate a login and password...?
>
Why don't you just do this:
>
using System.Director yServices;
>
public static bool Logon(string pstrDomain, string pstrUser, string pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new DirectoryEntry( "LDAP://" + pstrDomain,
pstrUser, pstrPassword))
{
return !objADEntry.Nat iveObject.Equal s(null);
}
}
catch (System.Runtime .InteropService s.COMException)
{
return false;
}
catch (Exception)
{
throw;
}
}
>

Won't work, the OP is in a Windows NT4 domain not an ActiveDirectory domain, there is no
LDAP server on the DC. Also, using above (DirectoryServi ces aka. ActiveDirectory ) to
authenticate a windows user is bad practice, I keep saying this.

Willy.

[Mark Rae]

Re: NTLM authentication

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:ei65ff$LHH A.3952@TK2MSFTN GP02.phx.gbl...

Won't work, the OP is in a Windows NT4 domain not an ActiveDirectory
domain, there is no LDAP server on the DC.

My mistake - apologies for not reading the OP closely enough...

Also, using above (DirectoryServi ces aka. ActiveDirectory ) to
authenticate a windows user is bad practice, I keep saying this.

Why? What would you recommend instead...?

[webrod]

Re: NTLM authentication

Don't consider the SAM a dtabase you can access, it's part of the NT security system and

actualy it's the security system (LSA)that performs the check by authenticating, just like
IIS is doing.

OK, so How can I ask LSA to authenticate a user credential?

IIS has everything in place to authenticate (provided it is correctly configured) a user
account using NTLM, something WSE is lacking.

ok, but what If I don't want to use IIS settings?
Actually, I tell you that because we are in the first days of the
projects.
We are sure that the client and the server will use Microsoft
technology, but maybe we are going to use JBOSS (!!) on the server side
or another server, but not a Microsoft one (so maybe we will not use
IIS).

That's why I would like to find a solution without using IIS settings
even if, today, we are using IIS.

So, maybe the solution is LSA?

Rod

[Willy Denoyette [MVP]]

Re: NTLM authentication

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:uqI$Wd$LHH A.3556@TK2MSFTN GP03.phx.gbl...

"webrod" <rodolphe.aoust in@gmail.comwro te in message
news:1167909149 .759083.317590@ 6g2000cwy.googl egroups.com...

>>

>I forgot to answer to your question.
>I can't use kerberos because I am on a Winnt system based on NTML not
>kerberos.
>>>
>>I don't get it, this is a local intranet and you are only running SQL on a server which
>>is
>>not a Domain member and you want to authenticate windows (local )accounts using NTLM
>>(that
>>is SQL integrated security)?

>>
>SQL? Why are we speaking about SQL? :)
>>

>
Sorry got confusd by the NTLM database ;-)
>

>Actually, I have users who belong to a domain (WinNT).
>So I have users in the SAM database.

Just to eliminate possible confusion, you have a NT4 domain and with a number of domain
members (servers/workstations) right?
You have WSE 3.0 clients connecting to WSE 3.0 services over a local network, and you want
to authenticate the client using NTLM, this because Kerberos is not an option (NT4 domain).
Now, WSE does not support NTLM network authentication , but you would like to authenticate
the clients (windows users). Well, network authentication is not possible at all, simply
there is no authentication handshake between the WSE server and client.
The only possibility you have to validate a user in such scenario is by passing the username
and password from the client to the server and let the server perform the "validation " of
the credentials supplied, but keep in mind that passing clear text secrets is insecure.
Validating the user at the webservice can be done by calling the Win32 API LogonUser(),
using the username, password and domain collected from the client as arguments. Note that
calling LogonUser has a serious drawback, it needs TCB privileges on W2K and lower. Note
also that the purpose of LogonUser is to authenticate and return an access token which can
be used to impersonate the caller, but I don't read this is a requirement.
You could also opt for a simple authentication scheme against a local identity store like
ADAM (sure this needs W2K3 or XP SP2), you could even authenticate against the NT4 DC over
NTLM using a ProxyUserObject in ADAM , but I seriously doubt this is all worth the trouble
you are not authenticating end to end anyway.

Willy.




Willy.

[Willy Denoyette [MVP]]

Re: NTLM authentication

"Mark Rae" <mark@markNOSPA Mrae.comwrote in message
news:%23X$f4t$L HHA.1248@TK2MSF TNGP02.phx.gbl. ..

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:ei65ff$LHH A.3952@TK2MSFTN GP02.phx.gbl...
>

>Won't work, the OP is in a Windows NT4 domain not an ActiveDirectory domain, there is no
>LDAP server on the DC.

>
My mistake - apologies for not reading the OP closely enough...
>

Well, this is quite confusing, the OP should have been more explicit in it's original
posting.

>Also, using above (DirectoryServi ces aka. ActiveDirectory ) to authenticate a windows
>user is bad practice, I keep saying this.

>
Why? What would you recommend instead...?

Well, it depends on so many things, like the OS versions, Domain versions (if any) client
types (windows non windows) and the final purpose of the authentication act.
Some alternatives are :
call Win32 LogonUser(), but while this validate a Windows user, it's purpose is to return an
access token.
use the SSPI set of security API's, these can be used to authenticate using different
protocols even for non Windows users. Unfortunately the V2 framework classes don't expose
all of their functionalities . V3 does a far better job, but here they relate more to the
WCF, than for generic authentication purposes.
On A W2K/W2K3 realm, you can use LDAP to authenticate against an AD domain, note here I'm
talking about LDAP, that is using System.Director yServices.proto col classes!!! The same
remark here as above, some network manager will not allow you to authenticate using LDAP
against a corporate Directory.


Anyway, using DirectoryServic es just for authentication is not the right way of doing, just
watch the amount of data passed when binding to the AD when doing so and you will understand
why (but there is more). The Directory is kind of a DB which can store a lot of objects,
authentication is part of the "authorizat ion" process, that is, before you can access the
objects stored in the directory, you have to prove "who you are" so that the
DirectoryServic e can perform authorization controls. So basically it's the start of a longer
transaction, but if you only perform the authentication step, you are needlessly hitting the
service. It's funny that people never authenticate against, let's say against a SQL server,
but find is quite usual to do it against a Directory server.

Willy.

[Willy Denoyette [MVP]]

Re: NTLM authentication

"webrod" <rodolphe.aoust in@gmail.comwro te in message
news:1167915069 .477134.325810@ s34g2000cwa.goo glegroups.com.. .

>Don't consider the SAM a dtabase you can access, it's part of the NT security system and
>actualy it's the security system (LSA)that performs the check by authenticating, just
>like
>IIS is doing.

>
OK, so How can I ask LSA to authenticate a user credential?
>

This is what you do when calling LogonUser() for instance.

>IIS has everything in place to authenticate (provided it is correctly configured) a user
>account using NTLM, something WSE is lacking.

>
ok, but what If I don't want to use IIS settings?
Actually, I tell you that because we are in the first days of the
projects.
We are sure that the client and the server will use Microsoft
technology, but maybe we are going to use JBOSS (!!) on the server side
or another server, but not a Microsoft one (so maybe we will not use
IIS).
>

But why do you want to use NTLM then, this is Windows only (and Samba) it's just meant to
authenticate user credentials over the network. Who tells you that your clients will be
running Windows? If you are serious about security you'll have to draw a line, you can't use
a mix of clients, services, OS etc.. without seriously thinking about a baseline security
infrastructure.
And honestly, NTLM is legacy, NT4 is dead, which make me think that this is not such a
baseline. What you need is a Kerberos realm (that is a W2K3 domain), and get rid of WSE 3.0,
migrate to WCF.
I would also suggest you to search the MSDN site for "Web Service Security: Scenarios,
Patterns, and Implementation Guidance
for Web Services Enhancements (WSE) 3.0.", it contains quite some valid information,
unfortunately there is not yet the same available for WCF.

That's why I would like to find a solution without using IIS settings
even if, today, we are using IIS.
>
So, maybe the solution is LSA?

Yes, if you want to call LogonUser() using Pinvoke, see my other post.

Willy.

[Mark Rae]

Re: NTLM authentication

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%23WOteNAM HHA.3944@TK2MSF TNGP06.phx.gbl. ..

>>Also, using above (DirectoryServi ces aka. ActiveDirectory ) to
>>authenticat e a windows user is bad practice, I keep saying this.

>>
>Why? What would you recommend instead...?

>
Well, it depends on so many things, like the OS versions, Domain versions
(if any) client types (windows non windows) and the final purpose of the
authentication act.

Makes sense.

call Win32 LogonUser(), but while this validate a Windows user, it's
purpose is to return an access token.

Yes - I've used that before when I've needed to know more than just a simple
yes or no...

use the SSPI set of security API's, these can be used to authenticate
using different protocols even for non Windows users. Unfortunately the V2
framework classes don't expose all of their functionalities . V3 does a far
better job, but here they relate more to the WCF, than for generic
authentication purposes.

OK - haven't really got into V3 yet...

On A W2K/W2K3 realm, you can use LDAP to authenticate against an AD
domain, note here I'm talking about LDAP, that is using
System.Director yServices.proto col classes!!! The same remark here as
above, some network manager will not allow you to authenticate using LDAP
against a corporate Directory.

Yes - that's what I'm currently doing via the code I offered a couple of
replies up... I take your point about network managers, though - so far, I
haven't come up against the scenario where I wasn't allowed to use AD to
authenticate a user, so maybe I've just been lucky...

Anyway, using DirectoryServic es just for authentication is not the right
way of doing, just watch the amount of data passed when binding to the AD
when doing so and you will understand why (but there is more). The
Directory is kind of a DB which can store a lot of objects, authentication
is part of the "authorizat ion" process, that is, before you can access the
objects stored in the directory, you have to prove "who you are" so that
the DirectoryServic e can perform authorization controls. So basically it's
the start of a longer transaction, but if you only perform the
authentication step, you are needlessly hitting the service.

OK - I wasn't really aware of the internal going-on during the
authentication process, but I guess it's a trade-off...

System.Director yServices
more processing overhead
managed code
returns a boolean, which is all I need

Win32 LogonUser()
less processing overhead
unmanaged code (pinvoke)
returns an access token, which I don't need and would rather not have
anyway

It's funny that people never authenticate against, let's say against a SQL
server, but find is quite usual to do it against a Directory server.

I authenticate against SQL Server for all my public websites - don't have a
choice, as I've never found a 3rd-party ISP who would permit AD access...:-)

[webrod]

Re: NTLM authentication

We are sure that the client and the server will use Microsoft
technology, but maybe we are going to use JBOSS (!!) on the server side
or another server, but not a Microsoft one (so maybe we will not use
IIS).

But why do you want to use NTLM then, this is Windows only (and Samba) it's just meant to
authenticate user credentials over the network.

I don't "want" to use NTLM. I have no other choice if the DC is a NT
domain.
Am I wrong??

Who tells you that your clients will be
running Windows?

The clients will use Windows. This is OUR requirement.
We do not want to support other clients.
Also the server side of our application will be installed on a 2000 or
2003 server (this is again one of OUR requirement) at the customer
place.
But we agree to support:
- customers who have a NT DC =NTLM no choice
- customers with AD =kerberos
And one of our requirement is to use the users from the DC. We don't
want to manage users password in our DB.
So:
- worksations =Microsoft (any version)
- DC =Microsoft AD or NT
- server =>Win2000 or 2003

>If you are serious about security you'll have to draw a line, you can't use
a mix of clients, services, OS etc.. without seriously thinking about a baseline security
infrastructure.
And honestly, NTLM is legacy, NT4 is dead, which make me think that this is not such a
baseline.

OK but what with my customers who have a NT DC?
When the client connect to my application and provide a user/password,
I need to check this user/password against the SAM database?
So How can I do that?

>What you need is a Kerberos realm (that is a W2K3 domain), and get rid of WSE 3.0,
migrate to WCF.

Same question: what with my customers who have a NT DC? I can't use
kerberos. Am I wrong?

I would also suggest you to search the MSDN site for "Web Service Security: Scenarios,
Patterns, and Implementation Guidance
for Web Services Enhancements (WSE) 3.0.", it contains quite some valid information,
unfortunately there is not yet the same available for WCF.
>

That's why I would like to find a solution without using IIS settings
even if, today, we are using IIS.

So, maybe the solution is LSA?

>
Yes, if you want to call LogonUser() using Pinvoke, see my other post.

ok, thanks I'll try that today.

Rod

[Willy Denoyette [MVP]]

Re: NTLM authentication

"Mark Rae" <mark@markNOSPA Mrae.comwrote in message
news:u1CktXAMHH A.3952@TK2MSFTN GP02.phx.gbl...

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%23WOteNAM HHA.3944@TK2MSF TNGP06.phx.gbl. ..
>

>>>Also, using above (DirectoryServi ces aka. ActiveDirectory ) to authenticate a windows
>>>user is bad practice, I keep saying this.
>>>
>>Why? What would you recommend instead...?

>>
>Well, it depends on so many things, like the OS versions, Domain versions (if any) client
>types (windows non windows) and the final purpose of the authentication act.

>
Makes sense.
>

>call Win32 LogonUser(), but while this validate a Windows user, it's purpose is to return
>an access token.

>
Yes - I've used that before when I've needed to know more than just a simple yes or no...
>

>use the SSPI set of security API's, these can be used to authenticate using different
>protocols even for non Windows users. Unfortunately the V2 framework classes don't expose
>all of their functionalities . V3 does a far better job, but here they relate more to the
>WCF, than for generic authentication purposes.

>
OK - haven't really got into V3 yet...
>

>On A W2K/W2K3 realm, you can use LDAP to authenticate against an AD domain, note here I'm
>talking about LDAP, that is using System.Director yServices.proto col classes!!! The same
>remark here as above, some network manager will not allow you to authenticate using LDAP
>against a corporate Directory.

>
Yes - that's what I'm currently doing via the code I offered a couple of replies up... I
take your point about network managers, though - so far, I haven't come up against the
scenario where I wasn't allowed to use AD to authenticate a user, so maybe I've just been
lucky...
>

No, this snip from the above post...

using (DirectoryEntry objADEntry = new DirectoryEntry( "LDAP://" +
pstrDomain, pstrUser, pstrPassword))
isn't using LDAP, it's using DirectoryEntry which is a wrapper around ADSI, what I mean is
using this:

using System.Director yServices.Proto cols;
....
using (LdapConnection ldap = new LdapConnection( "DomainName or DC name"))
{
LdapSessionOpti ons so = ldap.SessionOpt ions;
ldap.AuthType = AuthType.Kerber os; // or NTLM but ...
ldap.Bind(new NetworkCredenti al("username", "password", "domain"));
}
// done
...

this is far more lightweight and much faster than ADSI (DirectoryEntry ).
Note also the Kerberos AuthType, this has the advantage that authentication costs are low,
because of the life time of a kerb. ticket.

But again some System/network admins don't allow LDAP trafic, or only allow "DomainAdmi n"
Accounts, or "Exchange Admin"accounts to access the Directory. I'm consulting some financial
businesses and none of them actually allow access to their Corporate (Windows) Directory
server (no! they don't store client accounts ;-)), for obvious reasons. Some also don't want
to have a bunch of private LDAP stores (ADAM and the like) floating around, that's why they
apply policies that prevent LDAP trafic by closing the LDAP ports at a the firewall(s)
and/or routers.

>Anyway, using DirectoryServic es just for authentication is not the right way of doing,
>just watch the amount of data passed when binding to the AD when doing so and you will
>understand why (but there is more). The Directory is kind of a DB which can store a lot
>of objects, authentication is part of the "authorizat ion" process, that is, before you
>can access the objects stored in the directory, you have to prove "who you are" so that
>the DirectoryServic e can perform authorization controls. So basically it's the start of a
>longer transaction, but if you only perform the authentication step, you are needlessly
>hitting the service.

>
OK - I wasn't really aware of the internal going-on during the authentication process, but
I guess it's a trade-off...
>
System.Director yServices
more processing overhead
managed code
returns a boolean, which is all I need
>

Use Ldap as illustrated above.

Win32 LogonUser()
less processing overhead
unmanaged code (pinvoke)
returns an access token, which I don't need and would rather not have anyway
>

But there is even better, if you have to authenticate in a W2K3 realm, even in V2.

>It's funny that people never authenticate against, let's say against a SQL server, but
>find is quite usual to do it against a Directory server.

>
I authenticate against SQL Server for all my public websites - don't have a choice, as
I've never found a 3rd-party ISP who would permit AD access...:-)

True, but this is not what I'm talking about, or are you telling me that here SQL server is
only used for authentication? ?

Willy.

[webrod]

Re: NTLM authentication

You could also opt for a simple authentication scheme against a local identity store like

ADAM (sure this needs W2K3 or XP SP2), you could even authenticate against the NT4 DC over
NTLM using a ProxyUserObject in ADAM , but I seriously doubt this is all worth the trouble
you are not authenticating end to end anyway.

okay okay, I have done a test by mistake and I guess this is what you
are speaking about here.
My DC is NT.
I have installed ADAM, I have not added any users in ADAM (!!).
If I do this:
public static bool Logon(string pstrDomain, string pstrUser, string
pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new
DirectoryEntry( "LDAP://" + pstrDomain, pstrUser, pstrPassword))
{
return !objADEntry.Nat iveObject.Equal s(null);
}
}
catch (System.Runtime .InteropService s.COMException)
{
return false;
}
catch (Exception)
{
throw;
}
}

and provide the pstrDomain of ADAM, it works!!
It authenticates the user against the NT DC (SAM database) using ADAM!!
That's unbelievable!
I guess I can even get the Groups associated to the user. I am doing
more tests.
I think this is the solution to my problem, don't you think??
If my customers have a NT DC, then I can install ADAM and use it to
authenticate?
I guess this wat you were saying when you said "using a ProxyUserObject
in ADAM ".

Rod

[Mark Rae]

Re: NTLM authentication

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:OZKB41AMHH A.3588@TK2MSFTN GP06.phx.gbl...

No, this snip from the above post...
>
using (DirectoryEntry objADEntry = new DirectoryEntry( "LDAP://" +
pstrDomain, pstrUser, pstrPassword))
isn't using LDAP, it's using DirectoryEntry which is a wrapper around
ADSI, what I mean is using this:
>
using System.Director yServices.Proto cols;
...
using (LdapConnection ldap = new LdapConnection( "DomainName or DC name"))
{
LdapSessionOpti ons so = ldap.SessionOpt ions;
ldap.AuthType = AuthType.Kerber os; // or NTLM but ...
ldap.Bind(new NetworkCredenti al("username", "password",
"domain"));
}
// done
..
>
this is far more lightweight and much faster than ADSI (DirectoryEntry ).
Note also the Kerberos AuthType, this has the advantage that
authentication costs are low, because of the life time of a kerb. ticket.

Oh right - well, I'll take your recommendation on board and use that instead
of the ADSI way - thanks very much!

[Willy Denoyette [MVP]]

Re: NTLM authentication

"webrod" <rodolphe.aoust in@gmail.comwro te in message
news:1167922910 .784103.5320@q4 0g2000cwq.googl egroups.com...

>You could also opt for a simple authentication scheme against a local identity store like
>ADAM (sure this needs W2K3 or XP SP2), you could even authenticate against the NT4 DC
>over
>NTLM using a ProxyUserObject in ADAM , but I seriously doubt this is all worth the
>trouble
>you are not authenticating end to end anyway.

>
okay okay, I have done a test by mistake and I guess this is what you
are speaking about here.
My DC is NT.
I have installed ADAM, I have not added any users in ADAM (!!).
If I do this:
public static bool Logon(string pstrDomain, string pstrUser, string
pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new
DirectoryEntry( "LDAP://" + pstrDomain, pstrUser, pstrPassword))
{
return !objADEntry.Nat iveObject.Equal s(null);
}
}
catch (System.Runtime .InteropService s.COMException)
{
return false;
}
catch (Exception)
{
throw;
}
}
>
and provide the pstrDomain of ADAM, it works!!
It authenticates the user against the NT DC (SAM database) using ADAM!!
That's unbelievable!
I guess I can even get the Groups associated to the user. I am doing
more tests.
I think this is the solution to my problem, don't you think??
If my customers have a NT DC, then I can install ADAM and use it to
authenticate?
I guess this wat you were saying when you said "using a ProxyUserObject
in ADAM ".

Not exactly.....

when you call this...
DirectoryEntry( "LDAP://" + pstrDomain, pstrUser, pstrPassword))
followed by... (important!)
objADAM.NativeO bject.Equals(nu ll);

you are actually binding against the server pstrDomain using pstrUser, pstrPassword as
credentials for the bind (done by objADAM.NativeO bject.Equals(nu ll);).
That means that you are authenticating against the LOCAL account DB (the SAM of pstrDomain)
using NTLM. But, you can't use this to authenticate domain credentials (username\domai n). In
order to make this work for domain credentials, you need to set-up a UserProxy object in
ADAM so you can perform a bind redirection, but, and this is the BAD news , this requires an
AD domain (yes, I was wrong in suggesting it would work with NT4 domain DC's).
As I said earlier, NT4 is the culprit here, add AD domain to your requirements. Make your
customers understand that they need to get rid of this NT4 stuff, it's legacy and no longer
supported.

Willy.

[Mark Rae]

Re: NTLM authentication

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%235qVMTCM HHA.1912@TK2MSF TNGP02.phx.gbl. ..

As I said earlier, NT4 is the culprit here, add AD domain to your
requirements. Make your customers understand that they need to get rid of
this NT4 stuff, it's legacy and no longer supported.

I think that is the salient point here...

[webrod]

Re: NTLM authentication

Willy,

thanks you again for your answer.
I think you're right, we'll have to see if we can remove NT4 from our
requirement.
Anyway, I would like to ask you a last question regarding your answer.

Something is not clear.
You say:
"you are actually binding against the server pstrDomain using pstrUser,
pstrPassword as
credentials for the bind (done by objADAM.NativeO bject.Equals(nu ll);).
That means that you are authenticating against the LOCAL account DB
(the SAM of pstrDomain)
using NTLM. "

Then you say:
". But, you can't use this to authenticate domain credentials
(username\domai n). "

It looks like the opposite?? Or what is the difference between "binding
against the server pstrDomain using pstrUser, pstrPassword" and
"authentica te domain credentials (username\domai n)"?

I mean, with this code, I am not authenticating local user, I am really
authenticating users who belong to a domain. So this is exactly what I
want. Or maybe I misunderstand something?

The .NET script has been run on my XP workstation.
It belongs to a NT4 domain.
I have called the function this way:
Boolean test=Logon("loc alhost:50004", "BOB", "BOBPWD")

I have used localhost because ADAM is installed on my Windows XP
workstation (no users within ADAM and only one local account: admin).
Bob is registered on the NT4 domain (SAM db), he is not a local user.

So when I bind the local ADAM, it automatically authenticates the NT
domain user, right??
And I can authenticate any users within the SAM this way, it works.

Rod