NTLM authentication

[Willy Denoyette [MVP]]

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.

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

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

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

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]

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]

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.


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

ok, thanks I'll try that today.

Rod

 

[Willy Denoyette [MVP]]

Makes sense.


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


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


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.

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.

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]

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

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]

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]

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

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]

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

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.

 

[Willy Denoyette [MVP]]

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

Willy,

here is the firsts answers:


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 ).

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.

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


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)


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

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.