User autentification and access to "sister" domain resources

Archived from groups: microsoft.public.win2000.active_directory (More info?)

[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
4 answers Last reply
More about user autentification access sister domain resources
  1. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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

    "Gera" <Gera@discussions.microsoft.com> wrote in message
    news:4E3742D4-47E7-4BD6-837E-D0159C5EAEBC@microsoft.com...
    > [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
  2. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    [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


    "Ryan Hanisco" wrote:

    > 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
    >
    > "Gera" <Gera@discussions.microsoft.com> wrote in message
    > news:4E3742D4-47E7-4BD6-837E-D0159C5EAEBC@microsoft.com...
    > > [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
    >
    >
    >
  3. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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

    "Gera" <Gera@discussions.microsoft.com> wrote in message
    news:24A9B32A-2467-4DF1-BD86-48D12883EDB5@microsoft.com...
    > [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
    >
    >
    > "Ryan Hanisco" wrote:
    >
    > > 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
    > >
    > > "Gera" <Gera@discussions.microsoft.com> wrote in message
    > > news:4E3742D4-47E7-4BD6-837E-D0159C5EAEBC@microsoft.com...
    > > > [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
    > >
    > >
    > >
  4. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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
    >
    > "Gera" <Gera@discussions.microsoft.com> wrote in message
    > news:24A9B32A-2467-4DF1-BD86-48D12883EDB5@microsoft.com...
    > > [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
    > >
    > >
    > > "Ryan Hanisco" wrote:
    > >
    > > > 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
    > > >
    > > > "Gera" <Gera@discussions.microsoft.com> wrote in message
    > > > news:4E3742D4-47E7-4BD6-837E-D0159C5EAEBC@microsoft.com...
    > > > > [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
    > > >
    > > >
    > > >
    >
    >
    >
Ask a new question

Read More

Domain Active Directory Windows