Test

test

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

 

From http://blog.msfirewall.org.uk/2008/06/using-isa-server-2006-to-protect-active.html

An area that I get involved with my 'day job' quite a lot is protecting Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) extranets with ISA Server. Depeding on the customer needs, and security policy, this often results in an architecture design that includes a one-way Microsoft Active Directory forest trust. The key concept of this model is to solve two things; namely functionality and security.

So, lets look at functionality first - this is the 'forest trust' bit:

 

By using a forest trust we have a way for both internal and external users to share extranet resources. By its very nature, a forest trust is often popular because it ensures that internal users will be able to access extranet information transparently. By this we mean that users will be able to use their normal Windows credendials (that they are normally logged in with) to access extranet resources without the user even realising that this is occuring.

 

Next, lets look at security next - this is the 'one-way' bit:

 

Placing external users into an internal Active Directory environement, the 'Intranet forest', is never really a good idea, as the forest is the only real security boundary in Active Directory. Subsequently, a common solution is to create an 'Extranet forest' that is used to host external user credentials and create an isoltation point or segmented boundary from internal users. This makes the security people happy, and by way of a forest trust, this makes the users happy because it 'just works'. However, to make the security people even happier and to protect against account compomise in the Extranet forest, we ensure that the trust relationship between these two 'zones' is configured such that the Externet forest trusts the Intranet forest, but the Intranet forest DOES NOT trust the Extranet forest; hence the term 'one-way'. In this scenario, the Intranet forest would be termed 'Trusted' and the Extranet forest termed 'Trusting'.

So, what does this have to do with ISA then? Well, in addition to creating logical separation with forest boundaries, the model also normally includes some form of physical segmentation. This often results in the Extranet forest being placed into a perimeter network away from the internal network. In order to create this boundary and define the perimeter network, ISA Server is an ideal choice as the border firewall between these two security zones.

 

When you consider the communications that are required in order to support a forest trust, you will soon realise that you need a good application-layer firewall, ideally one that is able to inspect and control RPC traffic as this protocol is notoriously difficult to secure with most firewalls. If you combine this with the level of protection ISA Server can provide specifically for MOSS/WSS, it is not difficult to understand why ISA Server is often a key component in the overall security landscape for MOSS/WSS extranet solutions.

 

Obviously, I have over simplified things quite a bit and there are lots of other potential models (like the External Collaboration Toolkit for SharePoint for example) which could be used. However, a one-way forest trust model architetcure doesn't have to be just for extranets, they can pop up all over the place! You can also find a similar model in our old friend the Windows Server System Reference Architecture document set.

 

An overview of the architecture and concept being discussed is provided below:

 

So the the aim of this blog entry is to provide an overview of how to configure ISA Server to support this one-way forest trust architecture and define the necessary firewall policy rules and associated protocols to make it all work. This blog entry is by no means a 'ground up' walkthrough, but just gives a good overview of how ISA should be configured to allow for trust creation, validation and successful operation. In addition, I have tried to make my examples a little more generic by using a Web server, as opposed to SharePoint, but the overall concepts apply to lots of difference scenarios where a one-way forest trust is used across firewall boundaries.

 

One of the first things to realise with forest trusts is that they are not supported with Network Address Translation (NAT), hence your ISA Server will need a route relationship between the Extranet network and the Intranet network (or the other way around, as route relationships are bi-directional). Assuming this is in place, we now look at the necessary firewall policy rules to get it all working!

 

Like most security people, I like least privilege :-)
Consequently, I will always create more firewall policy rules than are necessarily needed, just to ensure that we have sufficient granularity to provide a minimal set of communications by disabling certain rules that we don't need all the time.

 

A lot of the communications or protocols defined in this blog entry are based upon the following whitepaper and KB article. However, I found that these articles weren't clear enough in places and needed 'improving' based upon real-world findings from using ISA Server as part of the solution with customers.

 

As we have a route relationship between our networks, we gain little advantage of using ISA Server server publishing in this particluar example, and therefore all firewall policy rules are defined as access rules. The RPC filter is also one of the only application filters that works with access rules, so this makes the decision the correct one in my opinion.

 

Please Note: ISA Server SP1 now allows for RPC UUID filtering even when using access rules, which historically required server publishing to be used. With this change, RPC access rules are now as powerful as RPC server publishing rules, which is nice!. Consequently, it is possible to extend the current solution even further by defininig a specific list of UUIDs used for forest trusts. However, this is going to take a fair bit of testing, so I think I will leave it for a future blog post!

 

So, based upon the above, we can summarise the necessary firewall policies as follows:

• AD Forest Trust: Allow Access for Forest Trust Creation/Validation
  
• AD Forest Trust: Allow Access for Conditional DNS Forwarding
  
• AD Forest Trust: Allow Access for Kerberos Client Authentication
  
• AD Forest Trust: Allow Access for NTLM Client Authentication
  
• AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)
  
• AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)
  
• AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)
  

An overview of each rule is provided below:

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

This rules allows the necessary communication required to initially setup and validate the trust relationship. Once the trust has been established, this rule can be disabled unless it is necessary to recreate/revalidate the trust for troubleshooting purposes. Following a least privilege approach, this step is strongly recommeneded for day-to-day operations.

AD Forest Trust: Allow Access for Conditional DNS Forwarding

This rule allows DNS servers in the Extranet forest to communication with DNS servers in the Intranet forest (and vice sersa). This is a based upon the use of conditional DNS forwarding which is needed to provide underlying name resolution services between the two AD environments.

Please Note: This is one of the few examples where using server publishing would have some security benefit as this would allow ISA Server to inspect and filter DNS as necessary. However, for this example an access rule is used for simplicity.

 

AD Forest Trust: Allow Access for Kerberos Client Authentication

 

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using Kerberos authentication. If Kerberos is not required, this rule is not required and should be disabled in order to adhere to least privilege.

AD Forest Trust: Allow Access for NTLM Client Authentication

 

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using NTLM authentication. It is very likely that this rule will need to remain enabled continuously and cannot be disabled, even in the event of using Kerberos.

 

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

 

This rule is needed to allow resources in the Intranet forest to be defined or 'picked' from the Extranet-Web server(s) themselves. For example within MOSS the object picker would be used to define SharePoint security permissions to a user or group in the Intranet forest. Without this rule, it will not be possible to select resources from the Intranet forest. Ideally this rule should be disabled most of the time and only enabled when adminiistrative changes are required.

 

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

 

This rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the Extranet Domain Controllers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

 

Again, this rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the ISA Servers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

So, now that we know what firewall polices are required to map the key communications required for everthing to function, we now need to look at the required policy objects in more detail. Before approaching this, it is worthwhile defining a few elements of the example environement that will be used as part of firewall policies:

 

Extranet-Web => Computer object for the Web server located in the Extranet forest. This would be running MOSS 2007 in our SharePoint analogy.

 

Extranet-DC1 => Computer object for the First Domain Controller in the Extranet forest.

 

Extranet-DC2 => Computer object for the Second Domain Controller in the Extranet forest

Intranet-DC1 => Computer object for the First Domain Controller in the Intranet forest.

Intranet-DC2 => Computer object for the Second Domain Controller in the Intranet forest.

 

Extranet Domain Controllers => Computer set for the Extranet Domain Controller computers.

 

Extranet Web Servers => Computer set for the Extranet Web server computers.

 

Intranet Domain Controllers => Computer set for the Intranet Domain Controller computers.

 

Internal Clients => Computer set to represent Intranet machines that are allowed access to the Extranet Web Servers. In reality, this may be all Intranet clients.

 

Based upon the firewall polices discussed above, the following pictures show a more detailed view of the rules including the necessary source, destination and protocol definitions for each set of communications (click to enlagre the pictures)

 

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

 

AD Forest Trust: Allow Access for Conditional DNS Forwarding

AD Forest Trust: Allow Access for Kerberos Client Authentication



AD Forest Trust: Allow Access for NTLM Client Authentication

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

Please Note: Based upon real-world testing and experience it was necessary to add both UDP and TCP transports for some protocols in order to prevent the object picker from experiencing delays during Intranet resource browsing tasks. Without both transports, it often became quite painful to administer Intranet resources whilst waiting for components to timeout and use an alternative transport. It was also necessary to add the 'LDAP GC (Global Catalog)' to the object picker firewall policy rules for everything to function correctly, but this deosn't appear to be documented in any of the Microsoft documents I have seen.

 

So, that should be all you need to get the trust established and have a fully functioning one-way forest trust. With this platform in place, it is now possible to start using ISA Server web publishing to provide secure access to Extranet web services. If you got everything correct, users should be able to authenticate to ISA Server using either Intranet or Extranet forest credentials by way of the forest trust.

http://www.pbbergs.com/windows/articles/TestDomain.html

 

This document was prepared for the building of a copy of the production Active Directory.  Following these steps will define how to rebuild the entire Microsoft Active Directory for a test domain.  *** Be careful ***

 
 

The first set of steps is to get a good pc into the production domain.  Once this pc is a member it needs to be promoted and be a healthy participant in the network.  The new DC then needs to be removed from the network before it is restarted (From its restore) to prevent any replication activity from damaging the production system.  Reconnection to the production system will create major problems in the production system

 
 

1.                  Shutdown ALL pc's within the test sub-net  (For this document it will be 192.168.1.x, gateway = 192.168.1.250), mask = 255.255.255.0

2.                  Remove the physical cable for the new pc and build the member server (This all should reside within the test domain) in production

        Install DNS (AD Integrated needed for this document)

3.                  Re-connect the cable and join the Domain_Name.com domain

        Select the IP Address 192.168.1.101

        Select the mask to 255.255.255.0

        Select the Gateway 192.168.1.250

        Point the DNS services to a production AD DNS server

4.                  Promote the server to a Domain Controller (DC) via dcpromo.exe

5.                  Promote the server to a Global Catalog Server

6.                  Let the system sit idle (2 hours) for Replication to sync up

        Point the DNS services to itself

7.                  Open up a command prompt

        dcdiag /v /test:ridmanager

        Make sure no errors with the rid manager

        Create an object on the new DC

        Physically disconnect the cable

        Bring up "Active Directory Users and Computers"

        By disconnecting you force the system to attach locally

        Create a test user with the account disabled

        Reconnect the physical cable

8.                  At  a command prompt type in NTBACKUP and do a system state backup saving the file to the local server

9.                  Demote this server to a member server with in the production domain (DCPROMO)

        Remove the NS record in the production environment

10.              Physically disconnect the server from the network by unplugging the cable from the hub

11.              Move the server to the test domain

12.              Re-Promote once this system has been disconnected and the ip changed

        Dcpromo

        Domain Name = Domain_Name.com

        NetBios Name = NetBIOS_Name

        Allow the promotion to create the DNS domain

        Once this DC is brought online (The DNS services on the member server can be shut down), define it with Integrated Active Directory DNS and all name space records will be restored.  Make sure to bring up DNS and select reload to refresh all data

        Active Directory Integrated

        Only Secure Updates 

13.              Reboot this server and After the POST Select F8

        Scroll down and select the option

"Directory Services Restore Mode (Windows 200x domain controllers only)"

14.              Log on as the administrator (This is within the old SAM account)

15.              Restore the System State from the previous NTBACKUP

16.              Re-boot the Domain Controller (DC)

 
 

Now that the DC is restored it needs to take control of all Flexible Single Master Operation roles (FSMO and the File Replication service).  Because of this utilities need to be loaded off of the Windows 200x install CD.  NTDSUTIL will perform most of these steps.  Since this is the first DC it needs to be a Global Catalog server and validate that it is the primary server in the domain.

 
 

17.              After the POST Select F8

        Scroll down and select the option

"Directory Services Restore Mode (Windows 200x domain controllers only)"

18.              Log on as the administrator (This is within the old SAM account)

19.              Install the Windows 200x Active Directory Administration Tools from the server cd

        D:\i386\ Adminpak.msi

20.              Install the Windows 200x Server Resource Kit from the server cd

        D:\support\tools\200xrkst.msi

21.              Re-boot the Domain Controller (DC)

22.              Log on as the administrator (This is with the AD account)

23.              Reset the ip address to the test domain, the restore resets the ip address.  Make sure to also point the dns server to itself as well

24.              Set this server as a Global Catalog (Ignore this step in a multi-domain environment and this DC holds the Infrastructure Master Role)

        Click Start, click Run, type mmc, and then click OK

        On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Sites and Services, click Close, and then click OK

        Double Click Active Directory Sites and Services

        Double Click Sites

        Double Click MP-Default-Site

        Double Click Servers

        Double Click the DC

        Right Click on NTDS Settings and Select Properties

        If the "Global Catalog" check box is not checked, check it

25.              All Flexible Single Master Operations (FSMO) roles need to reside on this DC

        Seize the PDC

        Click Start and then click Run

        In the Open text box, type ntdsutil

        Type roles

        Type connections

        Type connect to server  <DC name>

        Type q

        Type seize pdc

        Click "Yes"

        Seize the Infrastructure master role

        Type seize infrastructure master

         Click "Yes"

         Seize the Domain Naming master role

        Type seize domain naming master

        Click "Yes"

        Seize the schema master role

        Type seize schema master

        Click "Yes"

        Seize the RID Master Role

        Type seize rid master

        Click "Yes"

        Type q

        Type q

26.              Remove all other DC server objects (Repeat this step for each DC) KB216498

        Click Start and then click Run

        In the Open text box, type ntdsutil

         Type metadata cleanup

        Type connections

        Type connect to server <DC>

        Type q (The metadata cleanup prompt should now show)

        Type select operation target

        Type list domains (A list of domains should be displayed)

        Type select domain <#> (This is the domain of the server to be pruned)

        Type list sites (A list of sites should be displayed)

        Type select site <#> (This is the site of the server to be pruned)

        Type list servers in site (A list of servers should be displayed)

        Type select server <#> (This is the server to be pruned)

        Type q

        Type remove selected server (You should get confirmation of the removal)

        Type q

        Type q

27.              Remove all other DC orphaned records in Active Directory (Repeat this step for each DC) KB216498

        Click Start - Programs - Windows 200x Support Tools - Tools - ADSI Edit

         Delete the computer account in OU=Domain Controllers, DC=Domain_Name,DC=com

        Delete the FRS member object in CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=Domain_Name,DC=com

28.              Remove all other DC orphaned records in DNS

        Click Start - Programs - Administrative Tools - DNS

        Click <DC>.Domain_Name.com - Forward Lookup Zones - Domain_Name.com

        Delete the cname (alias) of all other DC's

        Delete the a record of all other DC's

29.              This DC needs to be the File Replication Service Master  (KB316790)

        Stop the File Replication service on the DC

        Make sure the following folders exist, if not create them

              C:\WINNT\SYSVOL\staging

              C:\WINNT\SYSVOL\sysvol  (Share as SYSVOL)

              C:\WINNT\SYSVOL\sysvol\Domain_Name.com

                          copy the contents of C:\WINNT\SYSVOL\domain to this folder

        Start Registry Editor (Regedt32.exe)

        Locate and then click the BurFlags value under the following key in the registry:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

        On the Edit menu, click DWORD, click Hex, type D2, and then click OK

        Quit Registry Editor

        Restart the File Replication Service

        Check the FRS event viewer to see if the system states that the sysvol is now being shared and defines all the paths

30.              Ensure that the DC has registered the proper computer role

        Enter net accounts at a dos prompt

        The computer role should say "primary"

 
 

Finally any information related to the old DC's need to be purged from AD.

 
 

31.              Re-boot the Authoritatively restored DC

32.              Within the production system delete the test user and computer account

33.              Within the production system delete the server object within the site that it was placed into for replication

 
 

Note: The File Replication Service can prevent the computer from becoming a Domain Controller (See below).  If when doing a dcdiag a message states that the rid pool is corrupt, what is probably happening is there are problems with replication.  Check the "File Replication Service" Event Log.  Also make sure that all sub-folders are available within c:\winnt\sysvol.

To re-test just the rid pool:                                dcdiag /v test:ridmanager

 
 

 
 

 
 

Never again connect this server to the production system!!!

 
 

 
 

When you restore a domain controller from backup (or when you restore the System State), the FRS database is not restored because the most up-to-date state exists on a current replica instead of in the restored database. When FRS starts, it enters a "seeding" state and then tries to locate a replica with which it can synchronize. Until FRS completes replication, it cannot share Sysvol and Netlogon.

If you restore all of the domain controllers in the domain backup, all the domain controllers enter the seeding state for FRS and try to synchronize with an online replica. This replication does not occur because all of the domain controllers are in the same seeding state. Setting the primary domain controller FSMO role holder to be authoritative forces the domain controller to rebuild its database based on the current contents of the system volume. When that task is completed, the Sysvol and Netlogon shares are shared. All the other domain controllers can then start synchronizing from the online replica

(See - KB316790)

Installing Office 2007 with Group Policy GPO

This eventually seemed to work for me:

1) Create a shared network location
2) Copy all the contents from the CD to this location
3) Run the setup.exe /admin and create the MSP file you like
4) Copy this MSP to the /Updates folder
5) Create a GPO as per normal and (for Office 2007 Pro +) choose the \ProPlus.ww\ProPlusww.msi
This gave me a "cannot validate" error which I think ties in with my next step so perhaps these steps should be reversed
6) Edit the config.xml file to suit your organisation: Note that it appears all the settings are COMMENTED OUT by default

Vista Home Premium updating from WSUS 3.0

To get Vista Premium to update from WSUS...

I simply exported the follwoing keys from my Windows 2008 server
-------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://MYWSUSSERVER:8530"
"WUStatusServer"="http://MYWSUSSERVER:8530"
"AcceptTrustedPublisherCerts"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"UseWUServer"=dword:00000001
"IncludeRecommendedUpdates"=dword:00000001
"AUPowerManagement"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000003
"AutoInstallMinorUpdates"=dword:00000001
"RebootWarningTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:00000005
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduleWaitTime"=dword:00000001


-------------------------------

Reboot and done.

FW: How to install and uninstall a program in Safe Mode - USEFUL TIP

From 4SYSOPS.COM

I've never really understood why uninstalling programs in Safe Mode isn't officially supported in Windows. The main purpose of Safe Mode is to troubleshoot Windows, and what usually causes the trouble? Right, misbehaving programs. This may not even be the fault of the program itself. Windows is a very complex system and sometimes unforeseeable things happen. If an application has been somehow damaged, it might not even be possible to uninstall it. For example, its service could hang immediately after the system boots, or other programs could interfere. In Safe Mode, Windows has reduced functionality, because only the core components have been loaded. In such an environment it is much easier to get rid of an application that has gone mad. Windows Safe Mode can be entered by pressing the F8 key before Windows boots up. In order to uninstall a program in Windows, the Windows Installer Service has to be running. If you try to uninstall software in Safe Mode, Windows will just inform you that: "The Windows Installer Service could not be started." Trying to start the service manually will only get you: "Error 1084: This service cannot be started in Safe Mode." The good thing is that it is not really difficult to outsmart Windows Safe Mode. All of the services that are allowed to start in Safe Mode are stored in the registry folder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\ All you have to do is to add a REG_SZ key with the service name (not the display dame) and the value data "Service" (without quotes). The service name of the Windows Installer Service is MSIService. As such, the REG file that adds the correct key looks like this: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer] @="Service" All you have to do is copy this to a text file, with the extension .reg, and drop the file into your tool box. Anytime you want to uninstall a program in Safe Mode, you just click on the REG file. You have to remove the key manually if you want to disable this feature. However, I think it usually won't do any harm. Please note that it is not always possible to uninstall software in Safe Mode because the corresponding installer program requires certain services to be running. In such a case you might just enable these services as well in Safe Mode by adding their service names to the Registry. The Service Name can be found in the service's properties in the Services snap-in. Note: If you know similar tips, please just mail them to If I like the tip, I will post it as an article on 4sysops with your name and a link to your blog or website.

Using Bit Locker on Virtual Machines

See this article:

http://blogs.msdn.com/virtual_pc_guy/archive/2008/01/23/using-bitlocker-under-virtual-pc-virtual-server.aspx

Note the comments as well.