Re: Not able to establish trust with another window 2003 domain
- From: "Paul Bergson [MVP-DS]" <pbergson@xxxxxxxxxxxxxxxxx>
- Date: Tue, 31 Oct 2006 07:20:33 -0600
The spaces in the lmhost names for the dc's and domain names is critical, be
sure that both are properly spaced, that is why I pointed to this in my
article I sent you to read.
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Eng" <Eng@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A3B6EA10-F93E-412F-BECC-0B566709E55A@xxxxxxxxxxxxxxxx
Hi Paul,
Thank you for your reply.
The lmhost file is working but is only working for my source domain. Which
mean, my source domain able to create a trust to the target, but when I
try
to create the trust from my target to my source, its fail again with the
same
error.
I try to remove the lmhost file and copy from my source domain pdc and
change the name and ip and try again. But its fail too.
On my source, I try to verify the trust after i had created the trust but
it
fail. (Strange, I can create the trust but I cannot verify the trust). I
open
event viewer and found that the following event id is log,
Event ID: 40960
Description:The Security System detected an authentication error for the
server cifs/ky-target.TARGET.LOCAL. The failure code from authentication
protocol Kerberos was "The referenced account is currently disabled and
may
not be logged on to.
(0xc0000072)".
I try to search MS website but fail to find a solution. Any idea what is
going on?
Thank you
Eng
"Paul Bergson [MVP-DS]" wrote:
You could try creating an LMHosts file and see if that helps.
Go to my website and lookup trust setup on an nt4 v 2003. This should
work
for 2003 v 2003, it even has a fool proof way to setup the LMHost
records.
http://www.pbbergs.com
Select articles and click on NT4 -v- Active Directory Trust
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Eng" <Eng@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9DD4123F-CA92-4087-BB2B-F05EDEDA9DB6@xxxxxxxxxxxxxxxx
Hi Paul,
Thank you for your reply.
I had followed the instruction from the website that you provide but
still
no luck. I still getting the same error message "The Local Security
Authority
is unable to obtain an ROC connection from the domain controller
DC1.target.local. Please check that the name can be resolved and that
the
server is available" .
I had verify that the RPC services is running and the name can be
resolve
on
each domain.
My source and target domain currently sitting on the same subnet. I
don't
think this is a problem right? correct me if i am wrong.
Is there any other way that I can try/ do to resolve my issue?
Thank you
Eng
"Paul Bergson [MVP-DS]" wrote:
I'm unclear as to what you have setup for dns. For now try setting up
a
secondary of each others primary and see if you have any luck.
Secondary
http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci1104911,00.html
http://support.microsoft.com/default.aspx/kb/816518/en-us
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Eng" <Eng@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CA618BAD-1FB8-44E5-8974-5CD31DB0AC6C@xxxxxxxxxxxxxxxx
Hi guys,
My mistake. when I ping using the "ping <gateway ip address> -f -l
1472" i
got reply. Not the "Packet needs to be fragmented but DF set". But
when
I
ping using the "ping <gateway ip address> -f -l 1742", then I get
the
"Packet
needs to be fragmented but DF set" reply. I think the 1st time I run
is
using
the wrong packet size.
Beside, I try to use my target domain to create a trust to one of my
production domain and its work. Only when I try to use my target
domain
to
establish a trust to my source, its fail.
I not sure what's going wrong but I believe that is something not
right
with
my source domain.
Hope to hear from you all guys soon.
Thanks
Eng
"Paul Bergson [MVP-DS]" wrote:
The error message you are recieving has to do with routing not
Windows.
The
size of the packets are too big for the routers and the routers are
not
allowed to break them up.
http://support.microsoft.com/default.aspx/kb/159211
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Eng" <Eng@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4B89048B-F082-44FD-8B23-D16A4B1DC24A@xxxxxxxxxxxxxxxx
Hi Jorge,
Thank you for your reply.
The trust that I try to create is external trust.
I had try to create conditional forwarding and perform the test
at
both
end
using
The result at below:nslookup -type=srv _ldap._tcp.pdc._msdcs.domain-name.com
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
C:\Documents and Settings\Administrator>nslookup -type=srv
_ldap._tcp.pdc._msdcs.target.local
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
_ldap._tcp.pdc._msdcs.target.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = ky-target.target.local
ky-target.target.local internet address = 10.30.101.228
:\Documents and Settings\Administrator>nslookup -type=srv
_ldap._tcp.dc._msdcs.target.local
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
_ldap._tcp.dc._msdcs.target.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = ky-target.target.local
ky-target.target.local internet address = 10.30.101.228
Also, I had check the event viewer but there is no Keberos
related
error.
I
had apply the patch 913446 but still no luck.
I try to ping the gateway using ping -f <gateway ip> -l 1742 and
it
reply
with the "Packet needs to be fragmented but DF set." Is this the
correct
result? I had read through your explanation but i still not
really
understand. Can you eleborate more on this? Thanks.
Thank you
Eng
"Jorge Silva" wrote:
Ok...
What type of trust are trying to stablish?
Use conditional forwarding and make sure that both ends can
resolve
eachother, which means that you must configure in both ends the
conditional
forwarding, then perform the test in both ends:
what results?nslookup -type=srv _ldap._tcp.pdc._msdcs.domain-name.com
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
nltest /dsgetdc:domain-name.com
When trying to stablish the trusts use both PDCe for both
domains.
The
PDCe
on both sides of the trust need to be able to resolve one
another.
also take another close look at
How to configure a firewall for domains and trusts
http://support.microsoft.com/kb/179442
If none of this work check
Remember generally broadcast traffic isn't allowed between
routers
(unless
you have relay agents, some switching/routers tha allow
this,etc).
The MTU can be an Issue Test your MTU from the problem server by
pinging
the
gateway of your router:
ping -f <router gateway IP> -l 1472
You will get one of three responses;
the ping will return, "Packet needs to be fragmented but DF
set."
or
it
will
timeout.
If the ping timeout, that means a downstream router has a
mismatched
MTU,
and is the probable reason for your connectivity issue.
Incrementally
reduce
the 1472 until the ping returns.
If you get the packet needs to be fragmented but DF set, at a
low
number
of
less than 1400, see if you can increase the MTU without a
timeout.
Ideally
you would really like a number as close to 1500 as you can
get.Carefull
MTU
to a much too low of a number and it would affect your network
performance.
Check the MTU max size on your router.
Also check:
Installing security update MS05-019 or Windows Server 2003
Service
Pack 1
may cause network connectivity between clients and servers to
fail
http://support.microsoft.com/default.aspx?scid=kb;en-us;898060
I also though about UDP fragmentation, do you see any kerberos
errors
on
your event viewer?
By default, Kerberos authentication uses User Datagram Protocol
(UDP)
to
transmit its data,UDP provides no guarantee that a packet sent
along
the
network will reach its destination intact. Thus, in environments
with
a
high
amount of network congestion it is common for packets to get
lost
or
fragmented on the way to their destination, because the only way
to
decrease
the likelihood of UDP fragmentation occurring is to reduce
network
traffic,
a usually impractical solution, it is almost always better to
configure
the
Kerberos authentication service to use TCP instead of UDP. TCP
provides a
guarantee that a packet that is sent will reach its destination
intact
and
can therefore be used in any network environment. In order to
force
Kerberos
authentication to use TCP, see
http://support.microsoft.com/kb/244474
--
I hope that the information above helps you
Good Luck
Jorge Silva
MCSA
Systems Administrator
"Eng" <Eng@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7BA0494F-DC18-441F-9AED-D34D04AC7C3D@xxxxxxxxxxxxxxxx
Hi Guys,
Thank you for the information. I had tried the suggestions by
you
all
guys
but no luck. All the result using the Port Query tools with
the
result
on
all
port is "listening" and "exit with return code 0x00000000. I
assume
all
the
port is opened and working.
Also, i install a new server on each domain and try to create
a
.
- Follow-Ups:
- Next by Date: Re: Manually Connect to near Active Directory DC Servers.
- Next by thread: Re: Not able to establish trust with another window 2003 domain
- Index(es):
Relevant Pages
|
Loading
