Re: Problems with Security Policy accross trust

From: Steven L Umbach (n9rou_at_nospam-comcast.net)
Date: 09/09/05


Date: Fri, 9 Sep 2005 09:52:10 -0500

It would be best to leave the domains in separate forests as forests are the
security boundary and while combining the domains into one forest is
possible but is not a trivial procedure to say the least. So what I gather
you are asking is that if it is possible for a user to logon to a computer
in the trusting domain and to receive Group Policy user configuration from
the trusted domain where their user account resides. I have not tried it
myself but I believe it is possible if you create a "forest" trust which
would require both domains and forests to be at Windows 2003 functional
level which means that there can only be Windows 2003 domain controllers in
each forest and dns must be correctly configured with stub zones and/or
conditional forwarding to do such and the Allow Cross-Forest User Policy and
Roaming Profiles policy setting is enabled for the appropriate Group Policy.
. This is a question you may also want to post in one of the Active
Directory newsgroups. The link below should be helpful as I believe it
directly answers some of your questions and I pasted the pertinent info
also. --- Steve

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/b44ba1b5-9f85-4bee-84c9-1994921658cd.mspx

Using Group Policy features across forests
The Windows Server 2003 family introduces a new feature called Forest Trust
that enables you to authenticate and authorize access to resources from
separate, networked forests. With trusts established between forests, you
can manage Group Policy throughout your enterprise, which provides greater
flexibility especially in large organizations. For more information on
forest trusts, see Forests in Group Policy Management Console.

This section describes Group Policy behavior in an environment with forest
trust enabled:

      . It is not possible to link a GPO to a domain in another forest.

      . With Forest trust, it is possible that a user in forest B could log
onto a computer in forest A. In this case, when the computer starts up, it
will process policy for the computer configuration from Forest A, as usual.
When a user from Forest B logs on, where they receive their policy settings
from depends on the value of the Allow Cross-Forest User Policy and Roaming
Profiles policy setting.

            . When this setting is Not Configured, no user-based policy
settings are applied from the user's forest. Instead, loopback Group Policy
processing will be applied, using the Group Policy objects scoped to the
computer. Users will receive a local profile instead of their roaming
profile.

            . When this setting is Enabled, the behavior is exactly the same
as Windows 2000 Server, User policy is applied from the user's forest and a
roaming user profile is allowed from the trusted forest.

            . When this setting is Disabled, the behavior is the same as Not
Configured.

      This setting is available on Windows Server 2003 located at: Computer
Configuration\Administrative Templates\System\Group Policy\Allow
Cross-Forest User Policy and Roaming Profiles.

      . It is possible to deploy Group Policy settings to users and
computers in the same forest, but have those settings reference servers in
other trusted forests. For example, the shares that host software
distribution points, redirected folders, logon scripts, and roaming user
profiles could be in another trusted forest.

      . Group Policy Modeling requires that both the user and the computer
be in the same forest. If you want to simulate a user from Forest A logging
on to a computer in Forest B, you must perform two separate Group Policy
Modeling simulations: one for the user configuration and the other for the
computer configuration.

      . Delegation across forests is supported for managing Group Policy.
For example, you can delegate to someone in Forest B the ability to perform
Group Policy Modeling simulations on objects in Forest A.

"Nathan" <Nathan@discussions.microsoft.com> wrote in message
news:2E467476-5282-427C-B113-ADFDA2287C8C@microsoft.com...
> Hi Steven thank you for your comments, could I ask for clarification on
> the
> comments I have made to Paul above? the important factor for us is that
> the
> GPO is implemented to lock the desktop down, if it will not pass from
> trust
> to trust is there a work around?
>
> Or are we talking making our domains work in the same forest, and if so is
> this hard to do with the forests been up and running?
>
> "Steven L Umbach" wrote:
>
>> I am not sure exactly what you mean by security policy but you can modify
>> security policy [user rights] on the trusting domain to restrict access
>> for
>> users from the trusted domain. You also must make sure that your share
>> and
>> ntfs permissions are what you need to restrict access to the principle of
>> least privilege. Keep in mind that permissions and user rights for
>> everyone
>> or authenticated users can allow access to users from a trusted domain.
>> So
>> instead of a share allowing access to authenticated users make sure that
>> only the specific global group is allowed access. You can also modify
>> security policy user rights so that instead of authenticated users you
>> specify the global groups you want to have the user right such as access
>> this computer from the network which may be domain users for the local
>> domain only.
>>
>> For an external trusts you can use ipsec in the trusting domain to
>> protect
>> computers from access from the trusted domain by having an ipsec
>> "require"
>> policy enabled on computers you do not want accessed. Ipsec by default
>> uses
>> kerberos authentication to create a security association before computers
>> can communicate. Ipsec however is somewhat complex to configure CORRECTLY
>> and domain controllers must be exempt from ipsec negotiation traffic for
>> protocols used for authentication process between domain controllers and
>> domain members. If you are interested in ipsec see the link below for a
>> great white paper on ipsec for domain isolation even if you only read
>> appendixes A - D.
>>
>> http://www.microsoft.com/technet/security/topics/architectureanddesign/ipsec/default.mspx
>>
>> If your domains both contain only Windows 2003 domain controllers you can
>> raise your domain and forest functional levels to be Windows 2003 and
>> then
>> create a forest trust. The advantage of a forest trust is that you can
>> use
>> "selective authentication" with the allow to authenticate permission to
>> further restrict access to domain computers in the trusting domain from
>> users in the trusted domain. There is no reason that a trusting domain
>> can
>> not be secured properly from users in the trusted domain if you implement
>> security features in Windows 2003 such as ipsec, ntfs and share
>> permissions,
>> selective authentication, and user rights properly on top of normal
>> security
>> best practices such as enforcing complex passwords for each domain. You
>> might want to read the free guides for Windows 2003 Server Security and
>> Threats and Countermeasures from the TechNet Security link below. The
>> Microsoft Press Windows Security Resource Kit edition two is also
>> something
>> you should purchase and read. --- Steve
>>
>> http://www.microsoft.com/technet/security/default.mspx --- TechNet
>> Security
>> link.
>> http://www.bookpool.com/sm/0735621748 --- Windows Security Resource Kit
>>
>>
>> "Nathan" <Nathan @discussions.microsoft.com> wrote in message
>> news:B854D8E5-13E2-457D-B8CE-C9F224342D64@microsoft.com...
>> > Please can any one help with the following issue.
>> >
>> > We have a link from our city learning centre to the local high school,
>> > we
>> > intend a one way incoming trust to allow users from the school to log
>> > onto
>> > our network with there school account.
>> >
>> > After sucessfully creating a trust a users can log on and they have
>> > access
>> > to their network area mapped, but there are no security setings. It is
>> > as
>> > if
>> > the security policy is denied access to the workstation to lock the
>> > security
>> > down. IE the kid can access network neighbourhood, run ETC ( A
>> > dangerous
>> > situation)
>> >
>> > Both Domain are windows 2003 server sp1, fully patched and in the same
>> > functional level, windows 2000 native. We do have firewall but I am by
>> > passing this until we can resolve this issue first.
>> >
>> > I will log a call with Microsoft if nes, but they want £759 as we can
>> > only
>> > order by PO been publically owned.PLEASE HELP
>> >
>> > What do I have to do to get the security settings from the schools AD
>> > controller to implement on our workstations accross the trust?
>>
>>
>>



Relevant Pages

  • Re: ADMT: Roaming Profiles
    ... dass MS das Verhalten zur Verarbeitung von User Group ... in der sich der Computer befindet nicht mehr abgearbeitet! ... Using Group Policy features across forests ... The Windows Server 2003 family introduces a new feature called Forest Trust ...
    (microsoft.public.de.german.windows.server.general)
  • Judge Voids Bush Policy on National Forest Roads
    ... Judge Voids Bush Policy on National Forest Roads ...
    (alt.gathering.rainbow)
  • Re: Cross Forest Authentication with a Machine Account and Select
    ... I actually opened a case with Microsoft on this Case SRX060314603874 ... Forest B we create a Domain local group and we add the Forest A Universal ... They were able to make it work with the settings below, ... policy in the Resource domain ...
    (microsoft.public.windows.server.active_directory)
  • Re: Policy question
    ... Too bad there are no forest wide policy. ... three domains and apply they on the domain level in each domain. ... If I want to modify a policy that will affect all 3 domains, ...
    (microsoft.public.windows.server.active_directory)
  • Re: lockdown desktop without Group Policy
    ... Group Policy settings. ... Logon as an administrator ... Right-click on the GroupPolicy folder and Properties - Security ... and enter "Edit Group Policy" for the name ...
    (microsoft.public.windows.terminal_services)