Re: Nesting domain groups under local groups
- From: "Lanwench [MVP - Exchange]" <lanwench@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 19 Mar 2007 10:01:14 -0400
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?
.
- References:
- Nesting domain groups under local groups
- From: fpbear
- Re: Nesting domain groups under local groups
- From: Lanwench [MVP - Exchange]
- Re: Nesting domain groups under local groups
- From: fpbear
- Re: Nesting domain groups under local groups
- From: Lanwench [MVP - Exchange]
- Re: Nesting domain groups under local groups
- From: fpbear
- Re: Nesting domain groups under local groups
- From: Lanwench [MVP - Exchange]
- Re: Nesting domain groups under local groups
- From: fpbear
- Nesting domain groups under local groups
- Prev by Date: Re: Making partition bigger
- Next by Date: Re: No Admin Access
- Previous by thread: Re: Nesting domain groups under local groups
- Next by thread: Re: registry
- Index(es):
Relevant Pages
|