If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Nesting domain groups under local groups
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? |
Ads |
#2
|
|||
|
|||
Nesting domain groups under local groups
fpbear wrote:
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. |
#3
|
|||
|
|||
Nesting domain groups under local groups
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? "Lanwench [MVP - Exchange]" wrote in message 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. |
#4
|
|||
|
|||
Nesting domain groups under local groups
fpbear wrote:
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. "Lanwench [MVP - Exchange]" wrote in message 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. |
#5
|
|||
|
|||
Nesting domain groups under local groups
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]" ahoo.com 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? |
#6
|
|||
|
|||
Nesting domain groups under local groups
fpbear 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]" ahoo.com 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? |
#7
|
|||
|
|||
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]" ahoo.com wrote in message ... fpbear 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]" ahoo.com 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? |
#8
|
|||
|
|||
Nesting domain groups under local groups
fpbear 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]" ahoo.com wrote in message ... fpbear 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]" ahoo.com 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? |
Thread Tools | |
Display Modes | |
|
|