NTLM authentication

[webrod]

Dear All,

let's say I have a web service.
I would like to authenticate users who try to access it.
I am on a winnt server so I will have to use NTLM but I don't want to
use IIS settings.

Is there a way to authenticate a user using WSE 3.0 against NTLM??

All the samples I have found on the web provide a solution based on
IIS.

Thanks for your answer

Rod

[Mark Rae]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@h40g2000cwb.googlegro ups.com...

let's say I have a web service.
I would like to authenticate users who try to access it.
I am on a winnt server so I will have to use NTLM but I don't want to
use IIS settings.

Is there a way to authenticate a user using WSE 3.0 against NTLM??

All the samples I have found on the web provide a solution based on
IIS.

Is the webservice on the public internet...?

[webrod]

Is the webservice on the public internet...?
no, not all.

[Mark Rae]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@s34g2000cwa.googlegro ups.com...

>Is the webservice on the public internet...?

no, not all.

OK - well, that certainly makes it easier.

So, then, presumably a user logs onto their workstation with their Windows
domain userid & password and then runs a desktop app (or maybe browses the
corporate intranet) which references a webservice running on a webserver in
the same domain as the user...? Is this right...?

What do you want to "know" next? Once you know what you need to know, what
do you need to do with that information...?

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@h40g2000cwb.googlegro ups.com...

Dear All,

let's say I have a web service.
I would like to authenticate users who try to access it.
I am on a winnt server so I will have to use NTLM but I don't want to
use IIS settings.

Is there a way to authenticate a user using WSE 3.0 against NTLM??

All the samples I have found on the web provide a solution based on
IIS.

Thanks for your answer

Rod

AFAIK WSE 3.0 does not support NTLM, why not use Kerberos?

Willy.

[webrod]

thanks you very much for your answer Mark.

What I want to know is a way to check a user credential against a NTLM
database.

Suppose I log on a workstation with BOB, then I want to start my .NET
application which access a web service as ALICE user.
My application will open a LOGIN form, then I want to provide ALICE
credential (login/pwd) to the web service.
Then my WS needs to check that the user (ALICE) really exists and check
the password.
(and if possible it should check the roles for authorization purpose
but I don't know yet if you can associate a role to a user with NTLM).

Actually, I am starting a project where my cutomers can have:
- AD (I use kerberos) =this is done
- ADAM (I do a LDAP bind against ADAM) =this is done
- winnt: I need to use NTLM (??) =this is in progress ;)

I don't want to use IIS setting, I would like to use something like
WSE.

Rod

[webrod]

AFAIK WSE 3.0 does not support NTLM, why not use Kerberos?
Willy,

I think you're right, I read somewhere that NTLM is not a public
protocol, that's why it is not supported by WSE.
So I am still wondering how I can check a user credential against a
NTLM database without IIS.

Is there something like a LDAP bind (as I did with ADAM)??

Thanks for your help.

Rod

[webrod]

AFAIK WSE 3.0 does not support NTLM, why not use Kerberos?

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

Rod

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@42g2000cwt.googlegro ups.com...

>AFAIK WSE 3.0 does not support NTLM, why not use Kerberos?

Willy,

I think you're right, I read somewhere that NTLM is not a public
protocol, that's why it is not supported by WSE.

Well, WSE3.0 is just an interim solution, WCF is the way to go and this one supports NTLM
authentication.

So I am still wondering how I can check a user credential against a
NTLM database without IIS.

NTLM database?
You mean authenticating using NTLM.

Is there something like a LDAP bind (as I did with ADAM)??

ADAM does not hold Windows identities, so can't be used here.
Willy.

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@i80g2000cwc.googlegro ups.com...

>AFAIK WSE 3.0 does not support NTLM, why not use Kerberos?

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)?
Well, I'm afraid the answer is - you can't use WSE 3.0 without IIS hosting for this. One
(the best long term) option is to use WCF, which supports SSPI and SPNEGO, that means it can
authenticate using Kerberos and fallback to NTLM when not available.
Another option is to drop your DAL into a COM+ server application (using
System.EnterpriseServices) and use ADAM with LDAP "authentication" in order to implement
role based authorization. The COM+ server can run with "Windows" account credentials having
access to SQL server. Note that you'll need to use SSL authentication between the client and
the WSE service, if you want to make this secure, it makes littel sense to protect SQL
access when one can catch the clear text password traveling between client and server.

Willy.

[Mark Rae]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@q40g2000cwq.googlegro ups.com...

- winnt: I need to use NTLM (??) =this is in progress ;)

I don't want to use IIS setting, I would like to use something like
WSE.

Ah, in which case, I think you might be out of luck as I don't believe WSE
supports NTLM authentication - have you considered WCF...?

[webrod]

Well, WSE3.0 is just an interim solution, WCF is the way to go and this one supports NTLM

authentication.

okay so I will read more information about WCF

So I am still wondering how I can check a user credential against a
NTLM database without IIS.

NTLM database?
You mean authenticating using NTLM.

actually I don't know how to say it :(
In Winnt, I guess the users are stored in a SAM database, right?
So is there a way to check a user credential against a SAM database??
Or, how can I check a user credential on winnt?

Is there something like a LDAP bind (as I did with ADAM)??

ADAM does not hold Windows identities, so can't be used here.

OK, I don't use ADAM, it was just an example :)
Actually I use ADAM only if the customer who will buy the product do
not have a domain (workgroup) but this is another problem.
In my current configuration, this is a WinNT system, so I do not have
AD nor ADAM.
I have a SAM database and I was wondering If I could bind the SAM to
authenticate a user (like I would do it with ADAM).

SUopose you have this credential : ALICE / ALICE_PWD
How do you do to check if this user (ALICE) really exist in the domain
(in the SAM database) and if the password (ALICE_PWD) is the right
one??
Maybe it's impossible, I don't know.

Thanks again for your time and your answer.
Rod

[webrod]

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? :)

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.

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.

Rod

[webrod]

Mark Rae wrote:

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@q40g2000cwq.googlegro ups.com...

- winnt: I need to use NTLM (??) =this is in progress ;)

I don't want to use IIS setting, I would like to use something like
WSE.

Ah, in which case, I think you might be out of luck as I don't believe WSE
supports NTLM authentication - have you considered WCF...?

not yet, you're right. Regarding WSE, it was an example. We can forget
it.

Rod

[Mark Rae]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@6g2000cwy.googlegrou ps.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.DirectoryServices;

public static bool Logon(string pstrDomain, string pstrUser, string
pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new DirectoryEntry("LDAP://" +
pstrDomain, pstrUser, pstrPassword))
{
return !objADEntry.NativeObject.Equals(null);
}
}
catch (System.Runtime.InteropServices.COMException)
{
return false;
}
catch (Exception)
{
throw;
}
}

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@6g2000cwy.googlegrou ps.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]]

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@6g2000cwy.googlegrou ps.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.DirectoryServices;

public static bool Logon(string pstrDomain, string pstrUser, string pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new DirectoryEntry("LDAP://" + pstrDomain,
pstrUser, pstrPassword))
{
return !objADEntry.NativeObject.Equals(null);
}
}
catch (System.Runtime.InteropServices.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 (DirectoryServices aka. ActiveDirectory) to
authenticate a windows user is bad practice, I keep saying this.

Willy.

[Mark Rae]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:ei**************@TK2MSFTNGP02.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 (DirectoryServices aka. ActiveDirectory) to
authenticate a windows user is bad practice, I keep saying this.

Why? What would you recommend instead...?

[webrod]

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]]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:uq**************@TK2MSFTNGP03.phx.gbl...

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@6g2000cwy.googlegrou ps.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]]

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:ei**************@TK2MSFTNGP02.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 (DirectoryServices 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.DirectoryServices.protocol classes!!! The same
remark here as above, some network manager will not allow you to authenticate using LDAP
against a corporate Directory.
Anyway, using DirectoryServices 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 "authorization" process, that is, before you can access the
objects stored in the directory, you have to prove "who you are" so that the
DirectoryService 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]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.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]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>>Also, using above (DirectoryServices 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.DirectoryServices.protocol 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 DirectoryServices 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 "authorization" process, that is, before you can access the
objects stored in the directory, you have to prove "who you are" so that
the DirectoryService 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.DirectoryServices
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]

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]]

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:u1**************@TK2MSFTNGP02.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>>>Also, using above (DirectoryServices 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.DirectoryServices.protocol 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.DirectoryServices.Protocols;
....
using (LdapConnection ldap = new LdapConnection("DomainName or DC name"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Kerberos; // or NTLM but ...
ldap.Bind(new NetworkCredential("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 "DomainAdmin"
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 DirectoryServices 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 "authorization" process, that is, before you
can access the objects stored in the directory, you have to prove "who you are" so that
the DirectoryService 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.DirectoryServices
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]

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.NativeObject.Equals(null);
}
}
catch (System.Runtime.InteropServices.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]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OZ**************@TK2MSFTNGP06.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.DirectoryServices.Protocols;
...
using (LdapConnection ldap = new LdapConnection("DomainName or DC name"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Kerberos; // or NTLM but ...
ldap.Bind(new NetworkCredential("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]]

"webrod" <ro**************@gmail.comwrote in message
news:11********************@q40g2000cwq.googlegrou ps.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.NativeObject.Equals(null);
}
}
catch (System.Runtime.InteropServices.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.NativeObject.Equals(null);

you are actually binding against the server pstrDomain using pstrUser, pstrPassword as
credentials for the bind (done by objADAM.NativeObject.Equals(null);).
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\domain). 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]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP02.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]

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.NativeObject.Equals(null);).
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\domain). "

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

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("localhost: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

[Mark Rae]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OZ**************@TK2MSFTNGP06.phx.gbl...

using System.DirectoryServices.Protocols;
...
using (LdapConnection ldap = new LdapConnection("DomainName or DC name"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Kerberos; // or NTLM but ...
ldap.Bind(new NetworkCredential("username", "password",
"domain"));
}
// done

This is working perfectly - thanks for the tip.

One final question: is the line "LdapSessionOptions so =
ldap.SessionOptions;" actually necessary...? Removing it doesn't (seem to)
make any difference...

[Willy Denoyette [MVP]]

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:ue**************@TK2MSFTNGP03.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OZ**************@TK2MSFTNGP06.phx.gbl...

>using System.DirectoryServices.Protocols;
...
using (LdapConnection ldap = new LdapConnection("DomainName or DC name"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Kerberos; // or NTLM but ...
ldap.Bind(new NetworkCredential("username", "password", "domain"));
}
// done

This is working perfectly - thanks for the tip.

One final question: is the line "LdapSessionOptions so = ldap.SessionOptions;" actually
necessary...? Removing it doesn't (seem to) make any difference...

No, it's not, this is only a snip of a much larger program which uses LdapSessionOptions ...
Sorry for the confusion.

Willy.

[Mark Rae]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:eN*************@TK2MSFTNGP06.phx.gbl...

No, it's not, this is only a snip of a much larger program which uses
LdapSessionOptions ...

Ah right...

Sorry for the confusion.

No problem - thanks again for the code.

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@i15g2000cwa.googlegr oups.com...

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.NativeObject.Equals(null);).
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\domain). "

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

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("localhost: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??

No, please enable account logon auditing in you local policies, and you will see how and who
is authenticating.
If you need to bind using a "domain" account, you need to apply the "domain\user" (or
"user@domain" ) syntax for the useriName property, how else would ADSI know which domain
controller stores BOB's credentials?
If you bind like you did, then ADSI assumes "BOB" is a local account, so the bind should
fail if BOB is not a local account or if it's password is not BOBPWD. Note that this bind
succeeds on V1.x of the framework, because here the default authentication type is "None",
which means no authentication check is done at all. Therefore you should specify
AuthenticationTypes.Secure and not rely on the default because this one is CLR version
dependent.

Willy.

[webrod]

Willy,

I am very surpised!!
I have tested with 4 employees in my companies.
My PC is a new one: there is NO local accounts.
They do NOT exist on my PC!!
This is true, this is my OWN PC, I mean I am the person who access this
PC and only me.
If I authenticate as I did againt ADAM with their login/pwd, it works.
If I enter a WRONG pwd, it doesn NOT authenticate (so it is the proof
that the default authentication type is NOT "None".)
And you can beleive me, there is no local users on my PC except:
Administrator, admin, ASPNET, IUSR_BW200120, console_de.

You are saying "ADSI know which domain controller stores BOB's
credentials?", this is a good question, I guess it knows the domain of
the current user so it tries to authenticates BOB with this domain, or
I don't know... But it does

Rod

Willy Denoyette [MVP] wrote:

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@i15g2000cwa.googlegr oups.com...

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.NativeObject.Equals(null);).
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\domain). "

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

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("localhost: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??

No, please enable account logon auditing in you local policies, and you will see how and who
is authenticating.
If you need to bind using a "domain" account, you need to apply the "domain\user" (or
"user@domain" ) syntax for the useriName property, how else would ADSI know which domain
controller stores BOB's credentials?
If you bind like you did, then ADSI assumes "BOB" is a local account, so the bind should
fail if BOB is not a local account or if it's password is not BOBPWD. Note that this bind
succeeds on V1.x of the framework, because here the default authentication type is "None",
which means no authentication check is done at all. Therefore you should specify
AuthenticationTypes.Secure and not rely on the default because this one is CLR version
dependent.

Willy.

[webrod]

to be clear they come (the 4 employees) on my PC to provide their
logon/pwd to my LOGON function). They do not run the application from
their PC, they run my application from MY PC, and ADAM is on MY PC.

Rod

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11*********************@s34g2000cwa.googlegro ups.com...

Willy,

I am very surpised!!
I have tested with 4 employees in my companies.
My PC is a new one: there is NO local accounts.
They do NOT exist on my PC!!
This is true, this is my OWN PC, I mean I am the person who access this
PC and only me.
If I authenticate as I did againt ADAM with their login/pwd, it works.
If I enter a WRONG pwd, it doesn NOT authenticate (so it is the proof
that the default authentication type is NOT "None".)
And you can beleive me, there is no local users on my PC except:
Administrator, admin, ASPNET, IUSR_BW200120, console_de.

You are saying "ADSI know which domain controller stores BOB's
credentials?", this is a good question, I guess it knows the domain of
the current user so it tries to authenticates BOB with this domain, or
I don't know... But it does

Say that the user is "administrator" with password "adminpwd", what administrator would be
used to authenticate, the LOCAL admin or the DOMAIN admin,?? According to you it would use
the domain administrator, well, I say it's not.
There must something wrong with your set-up or your code, really.

Please do yourself and us a favor and try to answer the following questions:
- What Framework version are you running on XP?
- Are you logged on into your domain or locally?
- Your DC is running NT4, right? .
- Enable (success and Fail) Logon auditing in your Local Security Policy. Clear the Security
EventLog and watch the security events after each bind. Note that this can' be done on NT4,
so you can only watch the local logon attempts.
- What happens if you run ldp.exe (from the ADAM prompt) and execute:
Connect to localhost port 389 (the defaults)
Bind using NTLM:
enter User (BOB or whatever you consider a valid domain account) and Password, leave
Domain empty
press advanced, select NTLM from the list and press OK
press OK in the Bind dialog
This should fail because authentication will be done to the LOCAL SAM and you said BOB
is non local (which I believe).
Now try the same specifying the domain name, this should succeeds.
- How does your path string looks like? Are you sure you specify the port like this:
DirectoryEntry(LDAP://server:389 ...
where server is the server name running ADAM and 389 the port on which the instance is
listening (here the default)

- Now, use the "domain\\user" syntax for the username in your DirectoryEntry constructor,
where domain is your logon domain (NT4) and user a domain account. This is the syntax that
makes it possible for the Security Provider to make a distinction between a local account
and a domain account.
- what's the result when running this code?
- and what logon events do you get in your Security log?

Willy.

[webrod]

Willy,

here is the firsts answers:

Please do yourself and us a favor and try to answer the following questions:
- What Framework version are you running on XP?

3.0

- Are you logged on into your domain or locally?

domain

- Your DC is running NT4, right? .

yes

- Enable (success and Fail) Logon auditing in your Local Security Policy. Clear the Security
EventLog and watch the security events after each bind. Note that this can' be done on NT4,
so you can only watch the local logon attempts.

don't know yet how to do it, I will try this afternoon.
Do you mean on my XP workstation or on the server?

- What happens if you run ldp.exe (from the ADAM prompt) and execute:
Connect to localhost port 389 (the defaults)
Bind using NTLM:
enter User (BOB or whatever you consider a valid domain account) and Password, leave
Domain empty
press advanced, select NTLM from the list and press OK
press OK in the Bind dialog
This should fail because authentication will be done to the LOCAL SAM and you said BOB
is non local (which I believe).

No, It works ;)
And it says "Authenticated as:GG\BOB" !!

GG is the domain name!! But I didn't enter the domain name in the logon
window, it was empty as you said ("...leave domain empty..."). So it
knows the domain even if I do not provide it!!

Now try the same specifying the domain name, this should succeeds.

Yes

- How does your path string looks like? Are you sure you specify the port like this:
DirectoryEntry(LDAP://server:389 ...

in my C# code I have:
new DirectoryEntry("LDAP://localhost:50004", "BOB","BOBPWD")

where server is the server name running ADAM and 389 the port on which the instance is
listening (here the default)

ADAM is running on my PC (XP).
The PORT is 50004 (I have installed several instances to do some tests,
then I have remove all of them except the last one which is listening
on 50004)

>
- Now, use the "domain\\user" syntax for the username in your DirectoryEntry constructor,
where domain is your logon domain (NT4) and user a domain account. This is the syntax that
makes it possible for the Security Provider to make a distinction between a local account
and a domain account.
- what's the result when running this code?

it authenticates

- and what logon events do you get in your Security log?

don't know yet I will answer you this afternoon

>
Willy.

thanks for your help

Rod

[webrod]

Willy,

here the lasts answers.
I have enabled the audit on my XP workstation.
When I use my code (without the domain name), here is the 2 logs I can
see:
FIRST LOG
Successful Network Logon:
User Name: BOB
Domain: GG
Logon ID: (0x0,0x4CB6F9)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: BW200120
Logon GUID: {00000000-0000-0000-0000-000000000000}

SECOND LOG
User Logoff:
User Name: BOB
Domain: GG
Logon ID: (0x0,0x4CB6F9)
Logon Type: 3

Does it mean something interresting for you?
GG is my domain (NT4), BW200120 is the name of my workstation.
Rod

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@q40g2000cwq.googlegr oups.com...

Willy,

here is the firsts answers:

>Please do yourself and us a favor and try to answer the following questions:
- What Framework version are you running on XP?

3.0

>- Are you logged on into your domain or locally?

domain

>- Your DC is running NT4, right? .

yes

>- Enable (success and Fail) Logon auditing in your Local Security Policy. Clear the
Security
EventLog and watch the security events after each bind. Note that this can' be done on
NT4,
so you can only watch the local logon attempts.

don't know yet how to do it, I will try this afternoon.
Do you mean on my XP workstation or on the server?

XP, that is where the client is running (and I suppose this is also where ADAM is running,
so I don't know exactly ).

>- What happens if you run ldp.exe (from the ADAM prompt) and execute:
Connect to localhost port 389 (the defaults)
Bind using NTLM:
enter User (BOB or whatever you consider a valid domain account) and Password,
leave
Domain empty
press advanced, select NTLM from the list and press OK
press OK in the Bind dialog
This should fail because authentication will be done to the LOCAL SAM and you said
BOB
is non local (which I believe).

No, It works ;)
And it says "Authenticated as:GG\BOB" !!

That's why I asked if you were logged on into a domain or locally. When logged on into a
domain, ldp uses the "Domain" name of the interactive user's logon session in this case, but
this will not work if your are logged on locally, just try it. Nor will it work when ADAM is
running on a remote server, because there you won't have a user login session running.

GG is the domain name!! But I didn't enter the domain name in the logon
window, it was empty as you said ("...leave domain empty..."). So it
knows the domain even if I do not provide it!!

He doesn't know the domain of BOB, he's using the current login domain. So, this works only
if BOB is a user of the same domain, but fails when not (for instance when BOB is a member
of another in a forest. That's why you should always use the "domain\user" format as
username property. Note that domain here is or the domain name for domain accounts or the
local machine name for local accounts, this to prevent ambiguity.

>

> Now try the same specifying the domain name, this should succeeds.

Yes

>- How does your path string looks like? Are you sure you specify the port like this:
DirectoryEntry(LDAP://server:389 ...

in my C# code I have:
new DirectoryEntry("LDAP://localhost:50004", "BOB","BOBPWD")

>where server is the server name running ADAM and 389 the port on which the instance is
listening (here the default)

ADAM is running on my PC (XP).
The PORT is 50004 (I have installed several instances to do some tests,
then I have remove all of them except the last one which is listening
on 50004)

>>
- Now, use the "domain\\user" syntax for the username in your DirectoryEntry constructor,
where domain is your logon domain (NT4) and user a domain account. This is the syntax
that
makes it possible for the Security Provider to make a distinction between a local account
and a domain account.
- what's the result when running this code?

it authenticates

Yep, see above.
But again, I want to stress some important points. When binding using the ADSI
(System.DirectoryServices) LDAP provider (LDAP://...) you are effectively using the SPNEGO
security provider (well, the ADSI provider does), that means that first Kerberos
authentication will be attempted and when this fails (and it will as NT4 does not support
Kerberos) it will downgrade to use NTLM, this is a slow process you can't even predict which
authentication protocol will be used. depending on the path specified, even a downgrade to
anonymous is possible.
Therefore SPS should never be used to validate user credentials, check the Remarks of
OpenDSObject API (wrapped by SDS.DirectoryEntry) in MSDN to know exactly why. If you can't
use the method described in KB180548, use the System.DirectoryServices.Protocol

Willy.

[Willy Denoyette [MVP]]

"webrod" <ro**************@gmail.comwrote in message
news:11**********************@i15g2000cwa.googlegr oups.com...

Willy,

here the lasts answers.
I have enabled the audit on my XP workstation.
When I use my code (without the domain name), here is the 2 logs I can
see:
FIRST LOG
Successful Network Logon:
User Name: BOB
Domain: GG
Logon ID: (0x0,0x4CB6F9)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: BW200120
Logon GUID: {00000000-0000-0000-0000-000000000000}

SECOND LOG
User Logoff:
User Name: BOB
Domain: GG
Logon ID: (0x0,0x4CB6F9)
Logon Type: 3

Does it mean something interresting for you?
GG is my domain (NT4), BW200120 is the name of my workstation.
Rod

Important for me, not really, maybe for you?
this says the LSA authenticated BOB as a Domain user on GG with a logon type 3 (network)
using NTLM and the NtlmSsp security provider.
Any failure authentication messages?, guess not, the local LSA running on an NT4 domain
member knows that the (NT4) DC LSA does not have the Kerberos SSP, so he doesn't even use
SPNEGO but NTLM directly.
Anyway, weird combination, using LDAP in a NT4 domain....
Willy.