Re: Permissions across 2 Forrest

Yea i get all that information. That is the basic lvl 100 info on DNS and
WINS. The problem I have is being able to take that information and adapt it
to my scenario and make sure it works right. To give you a full blown
example of whats going on is this:

I have 1 main network. On this network consist of 1 Forrest and 2 subnets.
192.168.1.x and 192.168.18.x. There is a legit reason behind this setup.
There is a DC on each subnet. This whole setup is forrest A. There is a
Primary DNS server on 1.x and the 18.x network along with DHCP and WINS. I
had to do it this way because it wouldnt work as the 18.x network being a
secondary since it has DHCP on it and it needs to integrate with DNS. Then
told the DNS to do zone transfers with other DNS servers on the list.

Later on at another location we created a new network called ForrestB and it
is 192.168.123.x network. It has its own DHCP with WINS and Primary DNS. One
day we decided to create a link between the 2 buildings for admin purposes.
After we did we then figured we would create the trust. We started off with
taking the DNS on each forrst and making the other secondary DNS servers.
For instance ForrestA DNS is now a secondary for Forrest B and vise versa.
Then we went into the Trust and Domains area to create the trust. Thats
where we been stuck ever since.

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:e6santAFHHA.3768@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:zvmbh.31433$6t.17262@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is the part where I would have to assume I have it set up correctly.
Microsoft and everyone who writes books on DNS is very vague on how to
really set these things up correctly due to the many configurations it
can be done in. I just spent time reading a book on DNS trying to learn
what I can about it hoping I have it set up correctly but it never really
answered my questions. Same goes for the WINS server as well.

You are absolutely correct that few if any books EVER
say "how to do it" explicitly so I am going to do that.

Here's the problem -- the answer (answers, really since
one is for WINS and one is for DNS but they are similar)
are SO SIMPLE that you might think I am not really doing
this.

Most books devolve into one (or many) of the specific
answers to some particular (set of) deployment(s) but
never state the basic, and very simple principles.

So here goes, remember this is VERY simple and we
only have to use enough words for you to "get it" and
most of even my simple answer will be repetative to
give you different ways to grasp it:

DNS:
DNS clients must specify STRICTLY a DNS Server (set)
on their NIC->IP properties which can resolve every name
that the client will (ever legitimately) need.

WINS:
WINS clients must use the same "WINS Database"*
as any resources 'servers' they wish to contact use.

*Same WINS Database means either the same WINS
server or a REPLICATING set of WINS Servers.

That is it. Really. The rest is just details, design
strategy, optimization, and common practice.

Really.

Everything else is details.

More specifically:

Internal DNS clients (especially using AD), which include
DCs and other servers, must use strictly the DNS Server
(set) which can resolve all internal names, and can forward
or recurse to resolve external names.

For simple setups (being specific here) your internal clients
will use the internal DNS server set provided by the domain,
and they will usually forward to the outside world for names
these DNS servers don't know (but remember this is not the
RULE -- that's above -- this is the practice.)

Common mistake (to avoid) is for admins to try to mix in
those external (firewall or ISP) DNS servers on the client
NIC->IP properties which will NEVER provide reliable
results.

Another common mistake is for admins to overlook (or
forget) that DCs and other servers are DNS clients TOO,
especially when "dynamic registration" is involved but
really always.

For more complicated child and multiple domain name
trees the DNS Server (set) used by the clients must be
able to resolve ALL of those other domains/trees either
directly (holding the zone), by conditional forwarding,
stub zones (holding the zone but not all the records), or
forwarding to a DNS Server which CAN do that.

Usually conditional forwarding is a safe choice but it
is not the only one (and sometimes not the best.)

WINS is similar but there is no concept of "multiple trees"
so the ENTIRE WINS database must be fully replicated
to all of the WINS servers (if clients are to be able to find
everything.)

Again, WINS clients include DCs (especially), resource
servers, and even (usually) the WINS Server itself --
remember it is a dynamic registration service so if the
"servers" aren't WINS clients they never register and
cannot be found by 'regular clients'. (And DCs for instance
are going to need to find each other both as Browse Masters
and for other purposes.)

(DCs usually win the Master Browser elections but
technically this is true for EVERY machine running
Windows because it is at least theoretically possible
that any Windows machine COULD win the Master
Browser job.)

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:%23DTdR57EHHA.2268@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:tJfbh.6212$wc5.1348@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
K Here is another example how I know the trust doesnt work right.

When I sit at Forrest A I can type in \\Forestbserver1\data and get
access denied. If I remote into the Forrest B Server and try to add
anyone from Forrest A it doesnt even give me that option to add anyone
because it doesnt see Forrest A.

Check you WINS Servers to make sure that
they replicate (if you have more than one)
that that every DC in both domains is registered
(set as a WINS client and succeeding at registration.)

Check your DNS to make sure the DNS in A can find
B, as well as B DNS can find A.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


If I add an account on Forrest B with the same username and password I
use on Forrest A I now can connect to the Forrest B server.

However While sitting on Forrest A I can go into the Security options
and it will allow me to add someone from Forrest B to have access to my
files here. Yet when I get on the Forrest B server and type in
\\ForrestAServer1\Data I get an error saying "No logon server available
to take care of my request".

The only equipment between the 2 servers is an HP 5308 Routing Switch.
We have all ports open and we are not filtering any information.

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:OcpqqTyEHHA.3576@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:lr_ah.240$Ga1.154@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is whats bizare.

From Forrest A-DC1 I can ping, net view, and even access stuff on the
Forrest B-DC1 Server when I use the correct account info. But if I
try to validate the trust it immediatly says it cant find the logon
server.

So you are saying that the trust FUNCTIONS for
purposes of resource access, but only fails the
"validation"?

If so the problem seems very small -- but still
interesting -- and tends to make me think that the
validation may be insisting on NetBIOS resolution
or using some port not used otherwise, while the
actual trust referrals are getting away with DNS
resolution.

There is NO firewalls between the 2 servers.

Or on the servers themselves, or any type of filtering
on any intermediate routers (people don't typically
call such router filterin "firewalls" today but they are
in fact a form of firewalling.)

When I get on Forrest B-DC1 I can ping, and I can net view but the
results of the new view are "Access Denied"
During Validation it also gives no logon server available.

Sounds very much like a NetBIOS resolution problem
although that is not a definitive or confirmed diagnoses.

I would surely look back to the WINS server and to
ALL DCs being WINS clients.

And I would surely double check for ANY form of
filtering (firewall or otherwise.)



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:OxpR%23jgEHHA.3600@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:5YD8h.17546$B31.17044@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I went back through it again and the only troubleshooting problem I
have is with the Net View.

Net View? Or browsing too?

If it is only Net View then you have to ask yourself exactly what
is going on there which is different from other commands....?

Net View must first resolve name to address (either DNS or
NetBIOS name) and then ask that particular server what
shares it offers.

Net View will only succeed if these things work:

1) Name resolves (or you use IP address in request)
2) IP connectivity, i.e., routing, works (which it must
for 'other' things to work, e.g., ping
3) The server IS a FILE Server and has at least one
share offered
4) No firewalls are interferring with server even though
in general routing is working.
5) Authentication/access permission itself is literally failing
You can eliminate or confirm #1 as the problem by
trying Net View with the IP:

net view \\IP.Address.Of.Server

#2 can be checked (as noted) by pingin and using other
commands.

#3 can be checked by doing a "net share" command ON
THAT file server (doesn't work remotely even when
things are working correctly.)

#4 should be checked again the local firewall especially,
to ensure that the XP (or Server BASIC) firewall allows
File and Print sharing etc.

#5 can (best) be checked after proving that 1-4 are ok by
using explicit credentials to connect to the server IPC$
share.

Net View \\ServerNameOrIP\IPC$ * /user:Domain\Username

"Domain" here can be the TARGET domain (and user there)
to eliminate trust issues OR a "local domain\user" to prove
that the trust authentication is working.

Forrest A can Net View B and get results. If Forrest B Net View A i
get access Denied. How do I fix that? I am not sure what
authentication its trying to do in order to fix it.

It is trying to follow either the implicit Domain
trusts (within a single forest) or the explicit trust
(forest or external) for domains outside the users
own forest.

Forrest A still says it cant find a DC in Forrest B. I have a
fealing I am just going to have to break down and spend the money
to call Microsoft. *sigh*

You can do that but the odds are pretty good you
just have a name resolution issue (either DNS or
WINS or even both) OR a firewall problem.

Oh there are NO firewalls between the servers. All ports are open.

I was traveling for Thanksgiving
with family a lot last week and so must apologize for
answering slowly and intermittently.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]





"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:OBnLp$SDHHA.4992@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:d2n8h.5526$yE6.368@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok went through all the troubleshooting you provided and
Microsoft. It still doesnt work and I have no clue why.
Regardless what I changed or tried the results are always the
same from both sides.

I can ping each other using the ip address and name. I did New
View from Forrest A to Forrest B and instead of showing access
denied like the white papers said it actually showed information.
However When I did Net View from B to A it gave the access denied
as shown in the white papers. It didnt say what the results your
suppose to get it just says that its expected.

So whats the next step?

Go back through everything again since if you
really get it right it will work.

WINS Server, (replicated if multiples), all Servers/DCs
and workstations as WINS clients on BOTH sides.

Share something from both sides.

Check for firewalls -- both personal/basic and intermediate
firewalls on routers/devices.

Check WINS server(s) for full registration of all machines,
especially DCs and file servers -- use both the WINS MMC
and BrowStat from the resource kit.

Check NBTStat - to see if NetBIOS names are being
resolved (before and after trying things.)

nbtstat -r
nbtstat -c

Do Manual "Net View" commands to determine if
anything is shared.

Do manual authentications to determine if authentication
works at all.

From A machine:
Net View * \\ServerInB\Share * /user:DomainA\UserInA
Net View * \\ServerInB\Share * /user:DomainB\UserInB

From B machine:
Net View * \\ServerInA\Share * /user:DomainA\UserInB
Net View * \\ServerInA\Share * /user:DomainA\UserInA

Use tools like Telnet (or better but not included with
Windows NetCat) to test for packet status through
firewalls. Better than PING since you can test on the
actual ports.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Paul Bergson [MVP-DS]" <pbergson@xxxxxxxxxxxxxxxxx> wrote in
message news:e6C8nBnCHHA.144@xxxxxxxxxxxxxxxxxxxxxxx
Did you go through the troubleshooting tips in my article as
well as the link that points to Microsoft's troubleshooting
tips?

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

"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in message
news:vgj7h.26373$TV3.5311@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yep the DC's show themselves in WINS and when I did the NBTSTAT
and it seems to work fine.


"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:%23UD6qWdCHHA.3916@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in
message
news:Yu_6h.16010$B31.7903@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
First I want to thank everyone for helping. Ok I checked the
article you posted and it is for NT4 and 2000. Both of my
Forrest are 2000.

As for the servers being a client I went and made sure they
are clients to the wins server. Since there is only 1 wins
server in each forrest I skipped any kind of replication for
now.

Did you do this for ALL DCs in BOTH domains/forests?
(It sounds like you did but I like to be explicit when the
problem seems to be hard.)

Did you go and LOOK in the WINS MMC to make sure all DCs
(at least) were registered with the WINS Server?

You might consider running NBTStat -RR on each DC and using
NBTStat to ensure the clients show themselves to be register
and
able to resolve NetBIOS names....

When went back to recreate the trust from Forrest A to
Forrest B it still says it cant contact the domain. It acts
like its not even trying to.

When I went to Forrest B and tried to recreate the trust from
B to A it actually goes through the whole process of creating
the trust unlike A did. It even creates the trust for both
sides. However when you click on Validate to see if its
working it first says "Can not validate see below" but the
next box says "Trust has been validated" "There were errors
contacting Forrest A. No logon server available.

When I went Back to Forrest A and looked it does show the
trust there but if you try to validate it you still get the
same error as before. Can not contact the domain.

I am still totally lost as to what to do.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Paul Bergson [MVP-DS]" <pbergson@xxxxxxxxxxxxxxxxx> wrote in
message news:%23pHBkDQCHHA.5012@xxxxxxxxxxxxxxxxxxxxxxx
Did you go through the link I told you? There should be
help within that.

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

"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in
message
news:qoI6h.25614$TV3.12808@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok I installed WINS on the Primary DC in each forrest. When
I log on the DC on Forrest A and try to Validate the trust
to Forrest B it says "No DC found in Forrest B."

When i go to the DC in Forrest B and try to Validate to
Forrest A it ask for a username and password. After typing
that in and hit OK it gives an error saying "No Logon
Server is available in Forrest A"

This is the exact same problem I had before I installed
WINS. What do I do now?


"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:ugMZrTBCHHA.3380@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in
message
news:9Ml6h.25083$TV3.14521@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks everyone. We are going to install WINS on the
servers ASAP. I was just going on the basis that AD only
uses DNS now days. At least thats what Microsoft says and
all the books I read say.

"Microsoft" does not actually say that.

If you are reading books that say that then they are trash
probably.

It's one thing for an admin (like you etc.) to be confused
but
anyone who writes a book without really understanding
these
systems has an obligation to get such things correct.


Hopefully this will fix the problem.

Probably.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


"Cary Shultz" <cwshultz@xxxxxxxx> wrote in message
news:eqLAYqxBHHA.1012@xxxxxxxxxxxxxxxxxxxxxxx
Chris,

You are in good hands with Jorge and Herb. I would
listen to what they are saying (which is essentially the
same....).

One thing that I might suggest that you use netdom (a
part of the Support Tools) to create the trust - once
everything else is in place - instead of using the GUI
(I am assuming that you are doing this from within the
Active Directory Domains and Trusts MMC). Netdom is a
very nice tool...

If you are not familiar with the Support Tools I might
suggest that you play with them. There are lots of
little goodies in there. Oh, and check out
http://www.joeware.net as well....

--
Cary W. Shultz
Roanoke, VA 24012

"Chris Peikert" <c.peikert@xxxxxxxxxxxxxxxxxx> wrote in
message
news:nBs4h.1493$6t.1150@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We have 2 forrest each with a single domain. We want
the administrator from both forrest be able to cross
forrest for admin purposes plus be able to assign
permissions across the forrest.

When you go to a folder on Forrest A and go to Security
it gives you the option to give someone access to the
folder from Forrest B.

However if your trying to do the opposite in Forrest B
and try to assign something to someone in Forrest A it
doesnt even see the Domain in Forrest A.

What is wrong here?









































.

Relevant Pages

  • RE: VPN Clients Not Registering in AD DNS
    ... via VPN, the DNS records of the VPN clients are unable to be registered. ... Windows 2003 server? ... please let me know whether the clients get the IP ...
    (microsoft.public.windows.server.sbs)
  • Re: Permissions across 2 Forrest
    ... I just spent time reading a book on DNS trying to learn what I ... Same goes for the WINS server as well. ... WINS clients must use the same "WINS Database"* ... If I remote into the Forrest B Server and try to add ...
    (microsoft.public.windows.server.active_directory)
  • Re: Permissions across 2 Forrest
    ... This whole setup is forrest A. ... integrate with DNS. ... WINS server as well. ... WINS clients must use the same "WINS Database"* ...
    (microsoft.public.windows.server.active_directory)
  • Re: Permissions across 2 Forrest
    ... This whole setup is forrest A. ... There is a Primary DNS server on 1.x and the 18.x network along with DHCP ... WINS clients must use the same "WINS Database"* ...
    (microsoft.public.windows.server.active_directory)
  • Re: Permissions across 2 Forrest
    ... Primary DNS server on 1.x and the 18.x network along with DHCP and WINS. ... Forrest B and vise versa. ... WINS clients must use the same "WINS Database"* ...
    (microsoft.public.windows.server.active_directory)