Re: Nesting domain groups under local groups



fpbear <dontsendhere@xxxxxxxxxx> wrote:
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.

You might just try this to see if it works. Remember, the
OTHERDOMAIN\otherusername is a member of the groups your app needs, right?


"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: 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)