External trust - assigning access to resources trusting domain

Please help.
(problem data)
I created External trust between
york.local = trusting domain, outgoing, Selective Authentication
tokyo.local = trusted domain, incomming, Domain Wide (no choice)
Selective Authentication.
DNS forwarders on both ends were setup.
I can ping accross both domains.

Problem1
From the internal domain side (chicago) I want to add a universal group from
the trusted domain (tokyo) to a universal group in the chicago domain. When
I open the group and click "add" the tokyo domain is not listed as a choice.

Problem2
When I try to add users or group objects to the share or NTFS permissions of
directories on the chicago server, it ask me for a user name and password
when I try to change the location of objects to tokyo. so i have to have an
admin account on the tokyo domain to see their directory data? what would be
necessary for a chicago domain admin to populate tokyo's AD catalog?

I can however, go the the server object in the chicago domain and choose the
security tab and add a group with the "allow autentication" access control
right from the tokyo domain's AD database. I can see tokyo from there. I
have to do this because I want to only allow users in tokyo to access one
server in chicago which is why I used selective authentication instead of
domain wide. So that part seemed to work.

thanks,

Ben

Hello benaug,

So you followed the way's described here?
http://technet.microsoft.com/en-us/l.../cc728307.aspx

What OS version do you have in both domains? For DNS i prefer using secondary
zones in windows 2000 and recommend stub zones for windows 2003 DNS servers.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Please help.
> (problem data)
> I created External trust between
> york.local = trusting domain, outgoing, Selective Authentication
> tokyo.local = trusted domain, incomming, Domain Wide (no choice)
> Selective Authentication.
> DNS forwarders on both ends were setup.
> I can ping accross both domains.
> Problem1
> From the internal domain side (chicago) I want to add a universal
> group from
> the trusted domain (tokyo) to a universal group in the chicago domain.
> When
> I open the group and click "add" the tokyo domain is not listed as a
> choice.
> Problem2
> When I try to add users or group objects to the share or NTFS
> permissions of
> directories on the chicago server, it ask me for a user name and
> password
> when I try to change the location of objects to tokyo. so i have to
> have an
> admin account on the tokyo domain to see their directory data? what
> would be
> necessary for a chicago domain admin to populate tokyo's AD catalog?
> I can however, go the the server object in the chicago domain and
> choose the security tab and add a group with the "allow autentication"
> access control right from the tokyo domain's AD database. I can see
> tokyo from there. I have to do this because I want to only allow
> users in tokyo to access one server in chicago which is why I used
> selective authentication instead of domain wide. So that part seemed
> to work.
>
> thanks,
>
> Ben
>

thanks!
I read the articles on technet, but I got a little more inforamtion from the
microsoft 70-294 exam book.

Server 2003 SP2 with domain and forest functional levels at server 2003 on
both sides.

I created the stub zones - but it did not fix. so i deleted them and set
forwarders again. I think I see it now. Selective Authentication means
exactly what it appears to say - it is done at the resource level. Therefore
the trusting domain's active directory user and group objects are not
resources? So from the AD User and Computers in the trusting domain, trying
to nest a group from the trusted domain into a group in the trusting domain
is not possible?
Can anyone Confirm this?

What about Problem2?

What are benefit to stub zones instead of forwarders?

Ben


"Meinolf Weber [MVP-DS]" wrote:

> Hello benaug,
>
> So you followed the way's described here?
> http://technet.microsoft.com/en-us/l.../cc728307.aspx
>
> What OS version do you have in both domains? For DNS i prefer using secondary
> zones in windows 2000 and recommend stub zones for windows 2003 DNS servers.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>
> > Please help.
> > (problem data)
> > I created External trust between
> > york.local = trusting domain, outgoing, Selective Authentication
> > tokyo.local = trusted domain, incomming, Domain Wide (no choice)
> > Selective Authentication.
> > DNS forwarders on both ends were setup.
> > I can ping accross both domains.
> > Problem1
> > From the internal domain side (chicago) I want to add a universal
> > group from
> > the trusted domain (tokyo) to a universal group in the chicago domain.
> > When
> > I open the group and click "add" the tokyo domain is not listed as a
> > choice.
> > Problem2
> > When I try to add users or group objects to the share or NTFS
> > permissions of
> > directories on the chicago server, it ask me for a user name and
> > password
> > when I try to change the location of objects to tokyo. so i have to
> > have an
> > admin account on the tokyo domain to see their directory data? what
> > would be
> > necessary for a chicago domain admin to populate tokyo's AD catalog?
> > I can however, go the the server object in the chicago domain and
> > choose the security tab and add a group with the "allow autentication"
> > access control right from the tokyo domain's AD database. I can see
> > tokyo from there. I have to do this because I want to only allow
> > users in tokyo to access one server in chicago which is why I used
> > selective authentication instead of domain wide. So that part seemed
> > to work.
> >
> > thanks,
> >
> > Ben
> >
>
>
>

Hello benaug,

Both domains are in different forests, then create "Domain local groups"
instead of "universal groups"? Now you should have under "locations" also
the remote domain listed and can add user from the remote domain.

On Chicago server you use an account from tokyo to add the groups? Make sure
the account has the correct permissions on the folders.

From another posting about DNS for trusts:
1. if your DNS server is running Windows 2000 --> use secondary zones
2. if your DNS server is running Windows 2003 --> you can use secondaries,
conditional forwarders or stub zones

* secondaries
- will require that you weaken security to some extent to permit the transfer
- susceptible to 'expiry' during periods of downtime that exceed the SOA
record's 'Expire after' value
- this can be increased but only on the or a primary copy of the zone
which you don't necessary have permission to alter
- cannot be AD-integrated and, therefore, imposes a potential admin. overhead
- if you have 2 or more of your own DNS servers, you must place a secondary
on each
- you can replicate one secondary from another if security or bandwidth
is a concern/problems
- limited fault-tolerance
- not self updating in the event of DNS reconfiguration on the other side

* conditional forwarders (not global forwarders)
- no weakening of security
- no unnecessary transfer of data
- expiry is no problem since they're not zones
- they are NOT load-balanced in any way
- the list of addresses you enter is ordinal or used in sequence following
the timeout period
- this places all the load on whichever DNS server comes first in the
list
- if you have 2 or more of your own DNS servers, you must configure
the conditional forwarders on each
- they can be AD-integrated
- if you do so, you'll simply compound the problem of load
- this may be moot depending on the scale involved
- limited fault tolerance
- not self updating in the event of DNS reconfiguration on the other side

* stub zones
- no weakening of security
- no unnecessary transfer of large amounts of data
- stub zones are built from the SOA, NS and necessary A records only
- well load-balanced
- all queries are answered
- from cache populated due to previous query for same record
- or by dividing the query load against all name servers defined by
the NS records within the master zone
- fault tolerant for the same reasons as they're load-balanced
- self-updating
- since stub zones are aware of all name servers serving the zone, they
can failover to any other
- this is true for all forms of name resolution
- capable of handling name server additions and removals with the exception
of the following
- if the name server configured as the the stub's master(s) is removed,
it will not auto failover to other name servers even though it possesses
sufficient knowledge to do so
(a design flaw in my opinion that I've yelled about for years)

.... that's all that springs to mind for now.

PS - as you may have noticed and within the context of this question -- I
dislike the use secondaries, I consider conditional forwarders as a lazy
solution and recommend stub zones wherever possible.


Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> thanks!
> I read the articles on technet, but I got a little more inforamtion
> from the
> microsoft 70-294 exam book.
> Server 2003 SP2 with domain and forest functional levels at server
> 2003 on both sides.
>
> I created the stub zones - but it did not fix. so i deleted them and
> set
> forwarders again. I think I see it now. Selective Authentication
> means
> exactly what it appears to say - it is done at the resource level.
> Therefore
> the trusting domain's active directory user and group objects are not
> resources? So from the AD User and Computers in the trusting domain,
> trying
> to nest a group from the trusted domain into a group in the trusting
> domain
> is not possible?
> Can anyone Confirm this?
> What about Problem2?
>
> What are benefit to stub zones instead of forwarders?
>
> Ben
>
> "Meinolf Weber [MVP-DS]" wrote:
>
>> Hello benaug,
>>
>> So you followed the way's described here?
>> http://technet.microsoft.com/en-us/l.../cc728307.aspx
>> What OS version do you have in both domains? For DNS i prefer using
>> secondary zones in windows 2000 and recommend stub zones for windows
>> 2003 DNS servers.
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>> Please help.
>>> (problem data)
>>> I created External trust between
>>> york.local = trusting domain, outgoing, Selective Authentication
>>> tokyo.local = trusted domain, incomming, Domain Wide (no choice)
>>> Selective Authentication.
>>> DNS forwarders on both ends were setup.
>>> I can ping accross both domains.
>>> Problem1
>>> From the internal domain side (chicago) I want to add a universal
>>> group from
>>> the trusted domain (tokyo) to a universal group in the chicago
>>> domain.
>>> When
>>> I open the group and click "add" the tokyo domain is not listed as a
>>> choice.
>>> Problem2
>>> When I try to add users or group objects to the share or NTFS
>>> permissions of
>>> directories on the chicago server, it ask me for a user name and
>>> password
>>> when I try to change the location of objects to tokyo. so i have to
>>> have an
>>> admin account on the tokyo domain to see their directory data? what
>>> would be
>>> necessary for a chicago domain admin to populate tokyo's AD catalog?
>>> I can however, go the the server object in the chicago domain and
>>> choose the security tab and add a group with the "allow
>>> autentication"
>>> access control right from the tokyo domain's AD database. I can see
>>> tokyo from there. I have to do this because I want to only allow
>>> users in tokyo to access one server in chicago which is why I used
>>> selective authentication instead of domain wide. So that part
>>> seemed
>>> to work.
>>> thanks,
>>>
>>> Ben
>>>