'TRUST' troubleshooting

  • Thread starter Thread starter Fran Rhomberg
  • Start date Start date
Steven,
I have all the screen shots for you (7 total), how do I
get these to you? I tried to send them to
your "(e-mail address removed)" account?, but this
failed and came back as "undeliverable". Can you send an
email to my work account, and I will reply back to it?
My work account is (e-mail address removed).
Thanks. - FR
 
Hi Fran,

I have sent mail to you. You can reply the mail with the screen captures as
attachment.

I will continue to help you.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.
 
Hi Fran,

I have got the screen captures.

This behavior can occur because the RestrictAnonymous registry value is set
to Level 2 on the Windows 2000 domain controller on which the Windows NT
4.0-based computer has its secure channel.

To resolve this behavior:

1. Set the RestrictAnonymous registry value to 0 or 1 on the Windows 2000
domain controller. This registry value can be found at:


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Value: RestrictAnonymous

Value Type: REG_DWORD

Value Data: 0x1 or 0x0(Hex)

2. Restart the domain controller.

3. Break, and then reestablish the trust.

MORE INFORMATION
================

The RestrictAnonymous registry value with a Level 2 setting must only be
used in "pure" Windows 2000 environments.

For additional information about the RestrictAnonymous registry value in
Windows 2000, click the article number below
to view the article in the Microsoft Knowledge Base:

246261 How to Use the RestrictAnonymous Registry Value in Windows 2000
http://support.microsoft.com/?id=246261

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.
 
Hi Steve,
Sorry for the lateness of this response. I got pulled
away last week on another issue. The trust is still
giving me the same error messages. here is what I did,
based on your instruction below:
1. On EFSMO(2000DC), The "RestrictAnonymous" registery
value was set to 1, and I changed it to 0.
2. On MFSPRIME(NT4PDC), The "RestrictAnonymous" registery
value did not exist, so I created a "REG_DWORD" registry
entry and set it to a value of 0.
3. I restarted both servers and let them sit overnight.
4. The next day, I broke the trust at both servers and
tried to recreate the trust, and received the same errors.
5. I broke the trust again and tried to create the trust
one more time and still nothing.
What do you think? Sorry this one is such a pain!
- FR
-----Original Message-----
Hi Fran,

I have got the screen captures.

This behavior can occur because the RestrictAnonymous registry value is set
to Level 2 on the Windows 2000 domain controller on which the Windows NT
4.0-based computer has its secure channel.

To resolve this behavior:

1. Set the RestrictAnonymous registry value to 0 or 1 on the Windows 2000
domain controller. This registry value can be found at:


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro
l\Lsa

Value: RestrictAnonymous

Value Type: REG_DWORD

Value Data: 0x1 or 0x0(Hex)

2. Restart the domain controller.

3. Break, and then reestablish the trust.

MORE INFORMATION
================

The RestrictAnonymous registry value with a Level 2 setting must only be
used in "pure" Windows 2000 environments.

For additional information about the RestrictAnonymous registry value in
Windows 2000, click the article number below
to view the article in the Microsoft Knowledge Base:

246261 How to Use the RestrictAnonymous Registry Value in Windows 2000
http://support.microsoft.com/?id=246261

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and
Click to expand...
confers no rights.
 
Hi Fran,

Let's make sure Everyone group was a member of ForeignSecurityPrinicpals.
Let's check the following registery key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

Let's also refer to the article to check the WINS database:

139410 Err Msg: There are Currently No Logon Servers Available...
http://support.microsoft.com/?id=139410

Let's see whether this works.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.
 
Hey Steven,
OK, I'm going to send you two screen shots in your email
account. (1) of my WINS Registrations, and (2)of the LSA
Registry Key. The "LMCompatibilityLevel" is set to "0",
and I didn't find a key
called "ForeignSecurityPrinicpals", or perhaps that is
not a key. In accordance to the kb article below, I did
setup a static mapping in WINS for the following:
(Entry in WINS on the 2000 FSMO DC)
Name: NT4PDC server name
IP: <10.1.x.x it's ip address>
DN: Name of NT4 Domain (trusting)
___________________
(Entry in WINS on the NT4PDC DC)
Name: 2000 domain controller name
IP: <10.50.x.x it's ip address>
DN: Name of 2000 Domain (trusted)

Here is the strange part. I've been working on this
issue for almost a month now. When I change the 2000DC
(EFSMO) back to the IP class of 10.1.1.x, the trust
starts to work again. I am able to map drives etc. Then
as soon as I change the IP Class to 10.50.5.x, it works
for a few days, and then stops. Should I change all my
2000 servers in the EMFS domain back to a 10.1.1.x IP
Class? I didn't think I had to do that, but it seems
like the only workaround. What are your thoughts.
- FR
 
Hi Fran,

Please check the WINS database for the domain controller in the related
WINS server.

Check the Windows 2000 domain controller on the WINS server on the Windows
2000 server. Make sure the 1c record of the domain controller is existed.

Check the Windows NT4 PDC on the WINS server in the NT4 domain. Make sure
the 1c record of the PDC is existed.

Sorry for the ForeignSecurityPrinicpals, you can ignore it.

Let's also try the following steps.

1. Grant the Windows 2000 domain users the access this computer from the
network right on the NT 4.0 PDC via user manager for domains
2. Grant the Windows NT4 domain users the access this computer from the
network right on the Windows 2000 DC via DC security MMC
3. Point the Windows 2000 DC to the NT4 WINS server as the second WINS
server
4. Point the Windows NT4 PDC to the Windows 2000 WINS server as the second
WINS server

Test whether this works.

Please also make sure the 10.1.x.x computers can communicate with the
10.50.x.x computer well. If there are switch or router between the 2
network, please make sure the switch and the router does not block any port
since the 2 domains need some ports to communicate with each other.

Since you said that the trust works well when the 2 domains are set to use
the same network, I think the problem may be caused by the router/switch.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.
 
IT WORKS, IT WORKS! YIPPIE!

Here was the resolution Steven:
It turns out WINS was the problem all along. Prior to
your instruction to turn WINS ON, I had enabled the
second NIC and assigned it a static IP address of
10.1.5.x, and the primary IP was 10.50.5.x, now when I
enabled WINS, I added the 2000PDC server to WINS via IP
address. Problem is I added my 2000PDC server under the
10.1.5.x IP address. Although I had WINS working, it was
doing so under the wrong NIC/IP.

Through our correspondence, we were looking at WINS quite
a bit, so I decided to investigate it closer. That's
when I noticed the 10.1.5.x IP assigned to the 2000PDC in
WINS. All I did was disable that NIC and then I ran a
NETDOM /QUERY command, and BOOM! It was successful.
Then I performed a Verify on the Trust, and it too was
successful, and then I tried mapping a drive from the
NT4Domain, and it too was successful.

If only I had disabled that NIC earlier, we would have
had this figured out a couple of weeks ago, and for that
I apologize. I am very grateful for your help and
persistence with this issue. Thanks for hanging in there
with me. If another problem arises, I look forward to
working with you. Thanks again.
- FR

-----Original Message-----
Hi Fran,

Please check the WINS database for the domain controller in the related
WINS server.

Check the Windows 2000 domain controller on the WINS server on the Windows
2000 server. Make sure the 1c record of the domain controller is existed.

Check the Windows NT4 PDC on the WINS server in the NT4 domain. Make sure
the 1c record of the PDC is existed.

Sorry for the ForeignSecurityPrinicpals, you can ignore it.

Let's also try the following steps.

1. Grant the Windows 2000 domain users the access this computer from the
network right on the NT 4.0 PDC via user manager for domains
2. Grant the Windows NT4 domain users the access this computer from the
network right on the Windows 2000 DC via DC security MMC
3. Point the Windows 2000 DC to the NT4 WINS server as the second WINS
server
4. Point the Windows NT4 PDC to the Windows 2000 WINS server as the second
WINS server

Test whether this works.

Please also make sure the 10.1.x.x computers can communicate with the
10.50.x.x computer well. If there are switch or router between the 2
network, please make sure the switch and the router does not block any port
since the 2 domains need some ports to communicate with each other.

Since you said that the trust works well when the 2 domains are set to use
the same network, I think the problem may be caused by the router/switch.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and
Click to expand...
confers no rights.
 
Hi Fran,

I'm glad to hear the problem is solved.

If you encounter anything wrong, please feel free to post here and we will
continue to help you.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu [MSFT]

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top