Unable to authenticate to untrusted domain NTLM v2 related issue

[lwoody]

Hi all

I am having a problem getting XP SP1 clients using NTLM v2 (AD domain
A) to authenticate (NT4 SP6 domain B) user credentials. These
credentails are used to map a network drive to member servers in the
NT4 based domain.

User logs on to XP SP1 using domain A user id / password. PCs are
domain members of A. They then map a drive to domain B using a
username / password for domain B for some development work.

At the moment, when the user enters their username/password/domain, the
member server logs the logon attempt but appear to fail to pass on the
request to Domain B's DC.

Both domains are on the same LAN. They are not trusted domains (and
they never will). There are no DNS/WINS issues. The DCs can ping each
other. This arrangement previously worked when Domain A was NT4 based.
It stopped working since it was replaced with XP / Active Directory.

Research suggests that I have add the (previously missing)
HKLM\system\currentcontrolset\control\lsa\lmcompatabilitylevel registry
key to both Domain B NT4 DC's with a value of 1.

This does not work.

XP SP1 clients set to "Send NTLMv2 response only"
NT4 Domain were set to "MS default" which is NTLM and now have the key
added which should negotiate NTLMv2?

As a note, from my XP SP1, I can authenticate to Domain B only to the
NT4 domain controllers before making the registry change (still works
afterwards) - but not to any of the member servers which are a mixture
of NT4, 2000, 2003 using the same user id.

Any ideas where I need to look?

 

[Steven L Umbach]

Does it work if the XP Pro client is configured to use send LM and NTLM?
NTLMV2 only allows for a thirty minute time skew I believe if that could be
a problem.

Steve

 

[lwoody]

Hi Steve

I am unable to change the XP clients as the security policy is forced
from Domain A (of which I am not a Domain Admin). Domain A contains

30,000 clients. Domain B has about 60. Domain B is used for application development for Domain A.

Unfortunately for me, I need to change Domain B to match Domain A but I
can't figure it out.

 

[Roger Abell [MVP]]

You have said that the XP clients in the uplevel domain
- can authenticate with and access resources that are directly
on a DC of the NT4 domain
- cannot authenticate to / access resources on a member of
that same NT4 domain
You also said that attempts to login on the members of the
NT4 are being logged on them. What are those events saying?

It actually appears that either the members are not configured
to support the NTLM requirements of the clients, or are not
successful in articulating with their DCs.

What happens if an attempt is made from on of these XPs to
access the same resources on the NT4 domain's members
not using an NT4 domain account but instead a machine local
account defined on the accessed member?

 

[Steven L Umbach]

I would try Roger's suggestion to see if you can access the other domain
computers via a local user account. If that works then it probably is a
problem with domain configuration somewhere. Another thing to try is try to
specify the IP address of the target server instead of name when trying to
access a share if neither local or domain account work. I know you said that
DNS and WINS are working properly but it is something that I always do as
part of troubleshooting network access problems. Another possible issue
could be incompatible security policy settings for "digitally sign
communications" in which case the XP Pro computers require it but the
servers in question are configured not to use it. That is probably a remote
possibility but if all else fails worth checking out though XP SP1 computer
did have a lot of problems with SMB signing which was cleared up in SP2. I
believe in particular there were problems if the server or computer required
digitally signed communications.

Steve

 

[lwoody7110]

Member server eventvwr security logs are as follows....

Method. Net use \\%servername\share
Server challenges me for username and password

The eventlog generates three events on the member server in Domain B.
(There are no events on the DCs)

#1

Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x179FE1)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: Domain A XP SP1 PC
Logon GUID: -
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.***.***.***
Source Port: 0


#2

User Logoff:
User Name: ANONYMOUS LOGON
Domain: NT AUTHORITY
Logon ID: (0x0,0x179FE1)
Logon Type: 3


#3

Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x17A07B)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: Domain A XP SP1 PC
Logon GUID: -
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.***.***.***
Source Port: 0




I can successfully map from XP SP1 to domain B member server using a
local account on the member server.

I agree with your assesment that member servers are not apparently
apparently supporting the NTLM requirements of the clients.

 

[lwoody7110]

Thanks Steve. I will look at this after Roger has had a chance to
advise me on the questions I have answered for him.

 

[Steven L Umbach]

After reading your original post more carefully it seems that there is no
trust between the domains. If your domain is not a trusted domain then you
can not use accounts in your domain to access recourses in the other domain.
You could either use local accounts on or use a user account in the other
domain from your computer.

Steve

 

[Roger Abell [MVP]]

After reading your original post more carefully it seems that there is no
trust between the domains. If your domain is not a trusted domain then you
can not use accounts in your domain to access recourses in the other
domain. You could either use local accounts on or use a user account in
the other domain from your computer.

I understood from the original post that that access is being done
using domain credentials defined in the NT 4 domain
<quote>

I am having a problem getting XP SP1 clients using NTLM v2 (AD domain
A) to authenticate (NT4 SP6 domain B) user credentials. These
credentails are used to map a network drive to member servers in the
NT4 based domain.

User logs on to XP SP1 using domain A user id / password. PCs are
domain members of A. They then map a drive to domain B using a
username / password for domain B for some development work.
</quote>

That he can access the share on the member from the XP SP1
when using a member machine local account rules out authentication
protocol issues on the XP SP1, and seemingly most all other network
issues (at least between the XP and the member).

The event logs posted show that the login is only anonymous on the
member when using NT4 domain credentials, at least if that part of
the info was not delete for posting privacy in the two events shown
where User is blank. I assume that is the IPC$ activity (?) . . .

But there is nothing in the NT4 DC logs (and logs checked on all
of the NT4 DCs were stated)

Steve, IIRC in NT4 when one set the lmcompatability level on a
DC it really was not firm, and the DC would downshift when needed.
If I am recalling correctly then that part of this would not be an issue
in the member being able to use its schannel for the authentication.

Since I will assume that other login with the member using credentials
from the NT4 domain work (from other machines in that domain or
local at that machine) I have then assumed that the member does
function well as an authenticating member in that domain.

That nothing shows in the NT4 DCs' logs make it seem like the member
believes it is doing a local login. But, there is no login failure for the
user
name in the member's logs, which contradicts that idea.

hmmm . . .
If this were "in-house" I would probably peek with netmon next to see
just exactly what is passing on the network to/from where during an
attempt from an XP SP1 in the uplevel domain.

Any other brilliant ideas, as you are well known for, Steve??

Roger

 

[Roger Abell [MVP]]

followups are in the other subthread in reply to Steve's post

 

[lwoody7110]

Hi Roger

Thanks for your assistance for far. We are on the same page with
regard this problem.

I did not remove any user ids from the eventlogs. I changed the
workstation name and masked the IP address.

The section for

Logon Process: NtLmSsp

might be important although I can't put my finger on it as my initial
research did occasionally mention
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. I have not been
clear on what this section does so I have left it alone. My XP access
to the domain B DCs have led me to think all is ok here.

With regard sniffing the LAN. Our network is managed by a 3rd party
and we are not allowed to sniff which makes life tricky. I will sneak
a sniff in sometime today/tomorrow.

I assume the best place to run the sniff is on the domain B member
server? Could you advise what I am looking for as I have never run a
sniff before.

 

[Roger Abell [MVP]]

It surely is looking to me, at this point, like this conforms well
to your initial assessment, that the issue is in the member referring
to its domain controllers.

The free, limited version on NetMon from Microsoft, if installed
on the member server (or better, if you have the liberty of testing
with a different member that would not have much load but that
does show the same behaviors) would only trap network traffic
of that machine. So, one would be looking to see what traffic
takes place with the domain controller after the login traffic from
the XP is received. Remember, with this NTLM authentication
the XP is talking with the member and then the member with the
domain controller named in the domain user account used by the
XP. IOW it is not that the member tells the XP to talk with the
domain controller and then bring back something - the member
handles it, so tracing traffic on the member should show all except
whether the domain controller actually hears it (and one could
infer that from the packet sequence seen on the member).

 

[Steven L Umbach]

Yikes. My bad. I had it right the first time.

As you say since local account can be used it is not an issue with lan
manager authentication level, ipsec, SMB signing, etc.

Curious that the security logs are not of much help. He should verify that
domain users in the domain that contain the servers he wants to access can
access the servers to try and rule out a problem with the servers referring
authentication to the DCs. Then he should verify that the domain account in
question can access the server or not while logged onto a computer in the
domain where the servers exist. If that works I would have to guess that for
some reason his computer is not using the credentials he expects - maybe
stored credentials?? Net use * \\server\share u:/domain\user password may be
worth trying.

Steve

 

[Roger Abell [MVP]]

Yep - and I just now thought of another aspect, which is verifying that
the NT 4 domain controllers are configured to log the login attempts.

 

[lwoody7110]

We have moved forward a bit - but not yet resolved.

I managed to get some assistance from a Domain A admin who is familiar
with network traces.

He confirmed with the trace capture that the behaviour seen so far,
that the member server does not appear to be passing credentials back
to XP. The domain A admin was able to change his XP to NTLM and this
then worked fine - so the issue is confirmed as a NTLMv2 issue. We
could then see logon success / failures on the domain B DCs.

So - this provides further evidence that the member servers are
dropping the authentication request when a XP client wishes to
authenticate against domain B.

I also noticed on the member server, that after changing the LAN
Manager setting to "Send LM & NTLM - use NTLMv2 session security if
negotiated" and running a RSoP on itself, showed that this policy was
not applied!

I am currently waiting for the domain A admin to report back with more
information as he took some more traces and the RSoP information away
with him to have a think.

 

[Roger Abell [MVP]]

Good. It can help greatly to take a peek at what is actually happening,
so I would bet that you folks will soon have this resolved.

 

[lwoody7110]

Fingers crossed.

I think I have just discovered the RSoP only displays policies assigned
from a DC. This would mean the results were correct.

I will post here once a solution is found.