Re: Nesting domain groups under local groups

Thanks Lanwench, I didn't think to use remote credentials. Although it is
tricky - the application checks the custom group membership, and based on
this, allows access to the SQL Server data objects and remote DCOM
components across the network. So the application doesn't just connect to a
file resource; it has been designed over the years to rely on these custom
groups for its internal security checking via various network communication
methods.


"Lanwench [MVP - Exchange]"
<lanwench@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uFF1v9aaHHA.4000@xxxxxxxxxxxxxxxxxxxxxxx
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
    ... access the other domain's file sharing resources, ... across the network with other users in this application. ... laptop/computer, using cached credentials, you can then connect to resources ... If the user disconnects ...
    (microsoft.public.windowsxp.security_admin)
  • 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: 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: 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: 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)