Re: Nesting domain groups under local groups

fpbear <dontsendhere@xxxxxxxxxx> wrote:
The users will need to be able to logon to another domain in order to
access the other domain's file sharing resources, to collaborate
across the network with other users in this application. Using
cached domain credentials would get the user on the machine, but
without access to the other domain's network resources (if I
understand correctly).

Ah, no, not at all. If you've logged in to your "usual" domain on a
laptop/computer, using cached credentials, you can then connect to resources
on the network you're physically connected to - whether it's another domain,
a home workgroup, or pretty much anything you can actually see/reach across
the network. All you have to do is supply the appropriate remote
credentials.

For example, one easy way in a comman line/batch file -

net use x: \\otherserver\share /user:OTHERDOMAIN\otherusername
/persistent:no

.....they will be prompted for the OTHERDOMAIN\otherusername password and can
supply it - it'll persist throughout the login session. Any other resources
on the OTHERDOMAIN servers/network that they then want to connect to, will
use the otherusername credentials.

That's only one way - but it's often the easiest.



Further, the user's data files are protected with NTFS file DACLs
that allow only the user's group access. If the user disconnects
from the home domain and logs onto another domain without the group
nesting scheme described previously, the user would be locked out of
their own files.

They don't disconnect. They *always* log into their own domain with cached
credentials. Users shouldn't have rights to change their domain membershipor
network config anyway, really.



"Lanwench [MVP - Exchange]"
<lanwench@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
I'm still confused, I guess. Why can't they belong to domainX, and
*always* log into domainX no matter where they are - whether they can
reach a domainX DC or not?



.

Relevant Pages

  • Re: Nesting domain groups under local groups
    ... it is tricky - the application checks the custom group membership, ... checking via various network communication methods. ... to access the other domain's file sharing resources, ... laptop/computer, using cached credentials, you can then connect to ...
    (microsoft.public.windowsxp.security_admin)
  • RE: 2003 Server multi sites
    ... Clients at the remote offices will still be able to log ... on and access resources if the network is available ... If your network is full ... long enough to run into the problem of cached credentials ...
    (microsoft.public.windows.server.general)
  • Re: Nesting domain groups under local groups
    ... I didn't think to use remote credentials. ... components across the network. ... access the other domain's file sharing resources, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... , it takes longer to investigate an attack and clean up after it than it does simply to nuke-and-pave, flatten-and-rebuild, whatever. ... then over time through precision monitoring of network ... Anything that does an interactive logon will store cached credentials, ... > domain admin account credentials), is a credential cached anywhere for> the ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... administrator accounts is a good mitigation. ... then over time through precision monitoring of network ... you have a way to limit exposure to this sort of expanded attack originating ... Anything that does an interactive logon will store cached credentials, ...
    (microsoft.public.windowsxp.security_admin)