Nesting domain groups under local groups

[fpbear]

I am wondering whether the following is good design practice. We have an
application that is locked down using domain GPOs, including setting
permissions on the user data files. Sometimes the users will travel and
attach these laptops to other domains (separate domains, not part of a
forest or trust). They log into these domains with another user account,
but they lose access to their data files because the SID for the account on
the file ACL is different on this new domain. So we are thinking of
creating local custom goups for the application and then nesting the
application's custom domain groups under them. When the user joins a
different domain then the domain admin just adds the domain group under the
local group. In this design, the local custom group is the group added to
the file permission. The application also checks to see if the domain user
is a member of the local group before access to features. Would this work?

 

[Lanwench [MVP - Exchange]]

I am wondering whether the following is good design practice. We
have an application that is locked down using domain GPOs, including
setting permissions on the user data files. Sometimes the users will
travel and attach these laptops to other domains (separate domains,
not part of a forest or trust). They log into these domains with
another user account, but they lose access to their data files
because the SID for the account on the file ACL is different on this
new domain. So we are thinking of creating local custom goups for
the application and then nesting the application's custom domain
groups under them. When the user joins a different domain then the
domain admin just adds the domain group under the local group. In
this design, the local custom group is the group added to the file
permission. The application also checks to see if the domain user is
a member of the local group before access to features. Would this
work?

I'm a bit confused as to what you mean by "attach these laptops to other
domains" or why they'd ever disjoin their corp domain to join another - why
aren't they always logging into *your* domain (with cached credentials) when
they're out of the office, so none of this would matter?

WinXP can belong to only one domain (or workgroup) at a time, but that
doesn't mean they can't pass along the appropriate credentials for their
"visiting" domain when they've made a network connection to it...

If I've misunderstood please correct.

 

[fpbear]

This is a government system and the domains all belong to the same agency.
Although it takes tremendous paperwork effort to make changes to a mission
critical system and get trusts established between the domain islands. So
even though they serve the same user base, the domain controllers remain
isolated. We might get a nice forest with cross domain trust within a few
years, but we will need to come up with a solution that works today for
traveling users.

Would nesting the groups in this manner cause any difficulties for
applications that have to check the role membership, or would it raise any
questions on Active Directory best practices?


in message

 

[Lanwench [MVP - Exchange]]

This is a government system and the domains all belong to the same
agency. Although it takes tremendous paperwork effort to make changes
to a mission critical system and get trusts established between the
domain islands. So even though they serve the same user base, the
domain controllers remain isolated. We might get a nice forest with
cross domain trust within a few years, but we will need to come up
with a solution that works today for traveling users.

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?

Would nesting the groups in this manner cause any difficulties for
applications that have to check the role membership, or would it
raise any questions on Active Directory best practices?

I'm really not sure how to answer that, sorry. You might try an AD group.

 

[fpbear]

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).

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.



"Lanwench [MVP - Exchange]"

 

[Lanwench [MVP - Exchange]]

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]"

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?

 

[fpbear]

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]"

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]"

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?

 

[Lanwench [MVP - Exchange]]

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]"

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]"
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?