User autentification and access to "sister" domain resources

[Guest]

[this is a long question, and difficult too]

I am in process of designing brand new AD structure for our customer.
A geographic placement is: 3 locations, let's say site A, site B and site C,
connected with 2 mbit links.

I propose a design with root domain and three child domains all with Windows
2003 Servers - pretty classic design (let's say, sites coincide with domains).
Every location (site) with 2 DCs for every child domain and one rootDC1 in
siteA and another rootDC2 in siteB.
All DCs are Global Catalogs.

A customer has some traveling users (notebooks with DHCP in use probably),
which should have possibility to login in any site and have access to local
(domain B) printers and files.

Situation in question is:
- group membership is by AGLP rule
- user_from_domainA arrives in siteB
- user_from_domainA gets IP address from siteB DHCP server
- user_from_domainA is trying to make logon in his remote DC in siteA while
sitting in siteB
- link to all DCs from domain A is suddenly broken, user_from_domainA PC can
log in using cached credentials
- links to nearest rootDC and domainB DCs are ok
- user_from_domainA still needs to print (or share files) to domainB printers
- user_from_domainA doesn't have any accounts in domainB

What will happen in this situation? I can't test this setup right now, so I
am hoping for help from colleagues...
Which DC is used in which moment? Is it enough to have domainB DC online and
valid cached credentials to traverse AGLP path?

And customer doesn't want to place addtional DC in every site (doesn't want
to place domainA DC in site B)
Is there the only solution to use one common domain spanning all 3 locations
or
use some siteB_guest account for access to domain B resources in this
situation?
Is it truly impossible to access "sister" domain resources while client's
own DCs are inaccesible?


Another smaller question about SUS in this setup: is it possible to approve
patches between server located in different domains?
I mean, have main SUS server on a rootDC1 (root domain), subordinate SUS
server on siteA_DC1 (child domain) and approve patches in this cross domain
way?


Thanks for any suggestions,

G.Simonson
IS engineer, MCSE

 

[Ryan Hanisco]

Gera,

Why is it that you want different domains at every site? It seems to make a
lot more sense to keep everything in one domain and define sites, delegating
administration. You really haven't given any really reason to segregate
domains -- political need, reflecting an NT4 structure from legacy (not too
valid a reason), need for boundaries in your Domain Security Policy.

What you are listing is exactly what I would do in an NT4 scenario, but this
doesn't seem like the way to go with AD. Make sure your site links are set
up correctly and your DNS is AD Integrated and you should be able to do
everything you need with OUs and Groups.

As to SUS... I have never tried doing updates from outside the domain, but
I don't see why it wouldn't work as long as the host can resolve the server
name and the SUS policy is set in the local domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[this is a long question, and difficult too]

I am in process of designing brand new AD structure for our customer.
A geographic placement is: 3 locations, let's say site A, site B and site C,
connected with 2 mbit links.

I propose a design with root domain and three child domains all with Windows
2003 Servers - pretty classic design (let's say, sites coincide with domains).
Every location (site) with 2 DCs for every child domain and one rootDC1 in
siteA and another rootDC2 in siteB.
All DCs are Global Catalogs.

A customer has some traveling users (notebooks with DHCP in use probably),
which should have possibility to login in any site and have access to local
(domain B) printers and files.

Situation in question is:
- group membership is by AGLP rule
- user_from_domainA arrives in siteB
- user_from_domainA gets IP address from siteB DHCP server
- user_from_domainA is trying to make logon in his remote DC in siteA while
sitting in siteB
- link to all DCs from domain A is suddenly broken, user_from_domainA PC can
log in using cached credentials
- links to nearest rootDC and domainB DCs are ok
- user_from_domainA still needs to print (or share files) to domainB printers
- user_from_domainA doesn't have any accounts in domainB

What will happen in this situation? I can't test this setup right now, so I
am hoping for help from colleagues...
Which DC is used in which moment? Is it enough to have domainB DC online and
valid cached credentials to traverse AGLP path?

And customer doesn't want to place addtional DC in every site (doesn't want
to place domainA DC in site B)
Is there the only solution to use one common domain spanning all 3 locations
or
use some siteB_guest account for access to domain B resources in this
situation?
Is it truly impossible to access "sister" domain resources while client's
own DCs are inaccesible?


Another smaller question about SUS in this setup: is it possible to approve
patches between server located in different domains?
I mean, have main SUS server on a rootDC1 (root domain), subordinate SUS
server on siteA_DC1 (child domain) and approve patches in this cross domain
way?


Thanks for any suggestions,

G.Simonson
IS engineer, MCSE

 

[Guest]

[current structure is Windows 2000 domain], thanks for SUS answer.

Reasons... well, to name a few:

- relatively slow and congested 2 mbit links between sites
- fewer replication in case of four domains users can't login centrally
- different groups of admins in every location, though managed "centrally"
but of course working separately
- separate password policies in domains
- easier restore in case of DC failure (in some cases...)
- less impact in case of critical error
- easier migration one site after another (specific case, migration time might
be very important)
- there will be more subnets (linked by 128/256 Kbits) and
users PC in every location in a future
- possibility to acquire and integrate some other companies
- locations are in different countries, thus regional/language settings may
need to differ
- at last, it seems to me that having own domains is easier to restrict
child-domain wide admins activity than to play with AD Delegations on one
common domain level
- ...

And it isn't, of course, a comlpete list of reasons because of complexity of
customer's environment.
On the other side, I understand your suggestion (MS always recommends to
start with single domain),
one domain solution is still possible, but then will arise all the problems
described earlier.

One more question emerged: is it possible in proposed design to use some GPO
at the root domain level and to propagate them down to child domains and
their objects? Can I make GP links across trusted domains?

Thanks and let's discuss further,
Gera

Gera,

Why is it that you want different domains at every site? It seems to make a
lot more sense to keep everything in one domain and define sites, delegating
administration. You really haven't given any really reason to segregate
domains -- political need, reflecting an NT4 structure from legacy (not too
valid a reason), need for boundaries in your Domain Security Policy.

What you are listing is exactly what I would do in an NT4 scenario, but this
doesn't seem like the way to go with AD. Make sure your site links are set
up correctly and your DNS is AD Integrated and you should be able to do
everything you need with OUs and Groups.

As to SUS... I have never tried doing updates from outside the domain, but
I don't see why it wouldn't work as long as the host can resolve the server
name and the SUS policy is set in the local domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[this is a long question, and difficult too]

I am in process of designing brand new AD structure for our customer.
A geographic placement is: 3 locations, let's say site A, site B and site C,
connected with 2 mbit links.

I propose a design with root domain and three child domains all with Windows
2003 Servers - pretty classic design (let's say, sites coincide with domains).
Every location (site) with 2 DCs for every child domain and one rootDC1 in
siteA and another rootDC2 in siteB.
All DCs are Global Catalogs.

A customer has some traveling users (notebooks with DHCP in use probably),
which should have possibility to login in any site and have access to local
(domain B) printers and files.

Situation in question is:
- group membership is by AGLP rule
- user_from_domainA arrives in siteB
- user_from_domainA gets IP address from siteB DHCP server
- user_from_domainA is trying to make logon in his remote DC in siteA while
sitting in siteB
- link to all DCs from domain A is suddenly broken, user_from_domainA PC can
log in using cached credentials
- links to nearest rootDC and domainB DCs are ok
- user_from_domainA still needs to print (or share files) to domainB printers
- user_from_domainA doesn't have any accounts in domainB

What will happen in this situation? I can't test this setup right now, so I
am hoping for help from colleagues...
Which DC is used in which moment? Is it enough to have domainB DC online and
valid cached credentials to traverse AGLP path?

And customer doesn't want to place addtional DC in every site (doesn't want
to place domainA DC in site B)
Is there the only solution to use one common domain spanning all 3 locations
or
use some siteB_guest account for access to domain B resources in this
situation?
Is it truly impossible to access "sister" domain resources while client's
own DCs are inaccesible?


Another smaller question about SUS in this setup: is it possible to approve
patches between server located in different domains?
I mean, have main SUS server on a rootDC1 (root domain), subordinate SUS
server on siteA_DC1 (child domain) and approve patches in this cross domain
way?


Thanks for any suggestions,

G.Simonson
IS engineer, MCSE

 

[Ryan Hanisco]

Gera,

You can do GP links across domains in the same forest. One of my clients is
a multinational with 6 domains and we do that. I have never tried it across
a forest boundary -- I get a bad feeling about that, but I can't give an
authoritative answer on that. (anyone??)

The need for different security policies is really the kicker. My concern
is that it seems that you are anticipating highly mobile users. The need to
reach authentication sources when intersite links are down is greatly
simplified in a single domain model as are the passing of GPOs. You're
right that delegation of administrative rights over Sites/OUs can be a
challenge.

If this is a large enterprise, I am sure you are using a mesh on your core
and distribution layers as well as HSRP. This kind of thing would
significantly reduce the potential for downed site links. Is there a chance
of a hot DR site that would have a DC for each domain to take over routing
and domain responsibilities in the case of failure? Even if its one of your
production sites?

Another potential solution would be to have one management domain as the
forest root and one child domain spanning the three sites. This would let
you aggregate full domain access and specify stronger security for the
administrative accounts delegated to the OUs in the child domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[current structure is Windows 2000 domain], thanks for SUS answer.

Reasons... well, to name a few:

- relatively slow and congested 2 mbit links between sites
- fewer replication in case of four domains users can't login centrally
- different groups of admins in every location, though managed "centrally"
but of course working separately
- separate password policies in domains
- easier restore in case of DC failure (in some cases...)
- less impact in case of critical error
- easier migration one site after another (specific case, migration time might
be very important)
- there will be more subnets (linked by 128/256 Kbits) and
users PC in every location in a future
- possibility to acquire and integrate some other companies
- locations are in different countries, thus regional/language settings may
need to differ
- at last, it seems to me that having own domains is easier to restrict
child-domain wide admins activity than to play with AD Delegations on one
common domain level
- ...

And it isn't, of course, a comlpete list of reasons because of complexity of
customer's environment.
On the other side, I understand your suggestion (MS always recommends to
start with single domain),
one domain solution is still possible, but then will arise all the problems
described earlier.

One more question emerged: is it possible in proposed design to use some GPO
at the root domain level and to propagate them down to child domains and
their objects? Can I make GP links across trusted domains?

Thanks and let's discuss further,
Gera

Gera,

Why is it that you want different domains at every site? It seems to make a
lot more sense to keep everything in one domain and define sites, delegating
administration. You really haven't given any really reason to segregate
domains -- political need, reflecting an NT4 structure from legacy (not too
valid a reason), need for boundaries in your Domain Security Policy.

What you are listing is exactly what I would do in an NT4 scenario, but this
doesn't seem like the way to go with AD. Make sure your site links are set
up correctly and your DNS is AD Integrated and you should be able to do
everything you need with OUs and Groups.

As to SUS... I have never tried doing updates from outside the domain, but
I don't see why it wouldn't work as long as the host can resolve the server
name and the SUS policy is set in the local domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[this is a long question, and difficult too]

I am in process of designing brand new AD structure for our customer.
A geographic placement is: 3 locations, let's say site A, site B and

site
C,

connected with 2 mbit links.

I propose a design with root domain and three child domains all with Windows
2003 Servers - pretty classic design (let's say, sites coincide with domains).
Every location (site) with 2 DCs for every child domain and one rootDC1 in
siteA and another rootDC2 in siteB.
All DCs are Global Catalogs.

A customer has some traveling users (notebooks with DHCP in use probably),
which should have possibility to login in any site and have access to local
(domain B) printers and files.

Situation in question is:
- group membership is by AGLP rule
- user_from_domainA arrives in siteB
- user_from_domainA gets IP address from siteB DHCP server
- user_from_domainA is trying to make logon in his remote DC in siteA while
sitting in siteB
- link to all DCs from domain A is suddenly broken, user_from_domainA

PC
can

log in using cached credentials
- links to nearest rootDC and domainB DCs are ok
- user_from_domainA still needs to print (or share files) to domainB printers
- user_from_domainA doesn't have any accounts in domainB

What will happen in this situation? I can't test this setup right now,

so
I

am hoping for help from colleagues...
Which DC is used in which moment? Is it enough to have domainB DC

online
and

valid cached credentials to traverse AGLP path?

And customer doesn't want to place addtional DC in every site (doesn't want
to place domainA DC in site B)
Is there the only solution to use one common domain spanning all 3 locations
or
use some siteB_guest account for access to domain B resources in this
situation?
Is it truly impossible to access "sister" domain resources while client's
own DCs are inaccesible?


Another smaller question about SUS in this setup: is it possible to approve
patches between server located in different domains?
I mean, have main SUS server on a rootDC1 (root domain), subordinate SUS
server on siteA_DC1 (child domain) and approve patches in this cross domain
way?


Thanks for any suggestions,

G.Simonson
IS engineer, MCSE

 

[Guest]

Thanks a lot for such extended reply, Ryan.

True, my biggest concern now is the mobile users ability to gain access
to another domain resources (through Global and Local groups) while they
cannot reach their own DC.
Could you (or anybody) confirm or deny that it is possible?
What is known about autentification path traversed in such situation?


G.

"Ryan Hanisco" rašė:

Gera,

You can do GP links across domains in the same forest. One of my clients is
a multinational with 6 domains and we do that. I have never tried it across
a forest boundary -- I get a bad feeling about that, but I can't give an
authoritative answer on that. (anyone??)

The need for different security policies is really the kicker. My concern
is that it seems that you are anticipating highly mobile users. The need to
reach authentication sources when intersite links are down is greatly
simplified in a single domain model as are the passing of GPOs. You're
right that delegation of administrative rights over Sites/OUs can be a
challenge.

If this is a large enterprise, I am sure you are using a mesh on your core
and distribution layers as well as HSRP. This kind of thing would
significantly reduce the potential for downed site links. Is there a chance
of a hot DR site that would have a DC for each domain to take over routing
and domain responsibilities in the case of failure? Even if its one of your
production sites?

Another potential solution would be to have one management domain as the
forest root and one child domain spanning the three sites. This would let
you aggregate full domain access and specify stronger security for the
administrative accounts delegated to the OUs in the child domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[current structure is Windows 2000 domain], thanks for SUS answer.

Reasons... well, to name a few:

- relatively slow and congested 2 mbit links between sites
- fewer replication in case of four domains users can't login centrally
- different groups of admins in every location, though managed "centrally"
but of course working separately
- separate password policies in domains
- easier restore in case of DC failure (in some cases...)
- less impact in case of critical error
- easier migration one site after another (specific case, migration time might
be very important)
- there will be more subnets (linked by 128/256 Kbits) and
users PC in every location in a future
- possibility to acquire and integrate some other companies
- locations are in different countries, thus regional/language settings may
need to differ
- at last, it seems to me that having own domains is easier to restrict
child-domain wide admins activity than to play with AD Delegations on one
common domain level
- ...

And it isn't, of course, a comlpete list of reasons because of complexity of
customer's environment.
On the other side, I understand your suggestion (MS always recommends to
start with single domain),
one domain solution is still possible, but then will arise all the problems
described earlier.

One more question emerged: is it possible in proposed design to use some GPO
at the root domain level and to propagate them down to child domains and
their objects? Can I make GP links across trusted domains?

Thanks and let's discuss further,
Gera

Gera,

Why is it that you want different domains at every site? It seems to make a
lot more sense to keep everything in one domain and define sites, delegating
administration. You really haven't given any really reason to segregate
domains -- political need, reflecting an NT4 structure from legacy (not too
valid a reason), need for boundaries in your Domain Security Policy.

What you are listing is exactly what I would do in an NT4 scenario, but this
doesn't seem like the way to go with AD. Make sure your site links are set
up correctly and your DNS is AD Integrated and you should be able to do
everything you need with OUs and Groups.

As to SUS... I have never tried doing updates from outside the domain, but
I don't see why it wouldn't work as long as the host can resolve the server
name and the SUS policy is set in the local domain.
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

[this is a long question, and difficult too]

I am in process of designing brand new AD structure for our customer.
A geographic placement is: 3 locations, let's say site A, site B and site
C,
connected with 2 mbit links.

I propose a design with root domain and three child domains all with
Windows
2003 Servers - pretty classic design (let's say, sites coincide with
domains).
Every location (site) with 2 DCs for every child domain and one rootDC1 in
siteA and another rootDC2 in siteB.
All DCs are Global Catalogs.

A customer has some traveling users (notebooks with DHCP in use probably),
which should have possibility to login in any site and have access to
local
(domain B) printers and files.

Situation in question is:
- group membership is by AGLP rule
- user_from_domainA arrives in siteB
- user_from_domainA gets IP address from siteB DHCP server
- user_from_domainA is trying to make logon in his remote DC in siteA
while
sitting in siteB
- link to all DCs from domain A is suddenly broken, user_from_domainA PC
can
log in using cached credentials
- links to nearest rootDC and domainB DCs are ok
- user_from_domainA still needs to print (or share files) to domainB
printers
- user_from_domainA doesn't have any accounts in domainB

What will happen in this situation? I can't test this setup right now, so
I
am hoping for help from colleagues...
Which DC is used in which moment? Is it enough to have domainB DC online
and
valid cached credentials to traverse AGLP path?

And customer doesn't want to place addtional DC in every site (doesn't
want
to place domainA DC in site B)
Is there the only solution to use one common domain spanning all 3
locations
or
use some siteB_guest account for access to domain B resources in this
situation?
Is it truly impossible to access "sister" domain resources while client's
own DCs are inaccesible?


Another smaller question about SUS in this setup: is it possible to
approve
patches between server located in different domains?
I mean, have main SUS server on a rootDC1 (root domain), subordinate SUS
server on siteA_DC1 (child domain) and approve patches in this cross
domain
way?


Thanks for any suggestions,

G.Simonson
IS engineer, MCSE