Tuesday, September 8, 2009

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:

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.

Sunday, August 9, 2009

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)

Sunday, July 5, 2009

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






























Wednesday, April 29, 2009

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.

Tuesday, April 28, 2009

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

tips-at-4sysops.com

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.

Wednesday, February 25, 2009

Join Samba 3 to Your Active Directory Domain

Always worth retrying….

http://www.enterprisenetworkingplanet.com/linux_unix/article.php/3487081/Join-Samba-3-to-Your--Active-Directory-Domain.htm

Join Samba 3 to Your Active Directory Domain

A popular thing to do with Samba these days is to join a Samba 3 host to a Windows Active Directory domain. You may freely set up any number of Samba servers in a Windows network without joining them to the domain. The advantages of domain membership are central management and authentication, and single sign-on. Using Winbind allows Linux clients to log on to the AD domain without requiring local Linux system accounts, which is a lovely time- and hassle-saver.

Presumably you already have a functioning Active Directory domain, and know how to run it. AD is very dependent on DNS (domain name system) so I'll assume your DNS house is also in order. On your Linux box you'll need Samba 3, version 3.0.8 or newer. Plus MIT Kerberos 5, version 1.3.1 or newer, and OpenLDAP. (The Samba documentation states that Heimdal Kerberos, version 0.6.3 or newer, also works. The examples in this article use MIT Kerberos.) Debian users need the krb5-user, krb5-config, krb5-doc, and libkrb53 packages. Red Hat and Fedora users need the krb5 and krb5-client RPMs.

First you should verify that your Samba installation has been compiled to support Kerberos, LDAP, Active Directory, and Winbind. Most likely it has, but you need to make sure. The smbd command has a switch for printing build information. You will see a lot more lines of output than are shown here:

root@windbag:/usr/sbin# cd /usr/sbin
root@windbag:/usr/sbin# smbd -b grep LDAP

HAVE_LDAP_H
HAVE_LDAP
HAVE_LDAP_DOMAIN2HOSTLIST
...
root@windbag:/usr/sbin# smbd -b grep KRB
HAVE_KRB5_H
HAVE_ADDRTYPE_IN_KRB5_ADDRESS
HAVE_KRB5
...
root@windbag:/usr/sbin# smbd -b grep ADS
WITH_ADS
WITH_ADS
root@windbag:/usr/sbin# smbd -b grep WINBIND
WITH_WINBIND
WITH_WINBIND

If you are in the unfortunate position of missing any of these, which will be indicated by a blank line, you need to recompile Samba. See Chapter 37 of the The Official Samba-3 HOWTO and Reference Guide.

Configure and Test Kerberos

Let's say our Active Directory domain server is bigserver.domain.net, and the Samba server is named samba1. This is the absolute minimum Kerberos configuration file, /etc/krb5.conf, for connecting to this domain:

'libdefaults'
default_realm = DOMAIN.NET

Related Articles

'realms' DOMAIN.NET = {
kdc = bigserver.domain.net
}

'domain_realms'
.kerberos.server = DOMAIN.NET

Use uppercase where it shows. Now try to connect, and mind your cases:

# kinit Administrator@DOMAIN.NET
Password for Administrator@DOMAIN.NET

Configure /etc/hosts

Even if your DNS servers are perfect in every way, it is a good idea to add important servers to your local /etc/hosts file. It speeds up lookups and provides a fallback in case the DNS servers go down:

192.168.10.5 bigserver.domain.net bigserver

Configure Samba

This example smb.conf shows a basic setup for a printer server and home shares. Shares are configured in the usual manner, only the global section changes when you join to an AD domain.

# Global parameters
'global'
workgroup = BIGSERVER
realm = DOMAIN.NET
preferred master = no
server string = Samba file and print server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000

'homes'
comment = Home Directories
valid users = %S
read only = No
browseable = No

'printers'
comment = All Printers
browseable = no
printable = yes
guest ok = yes

The workgroup is the name of your AD domain. Server string is a comment describing the server, make this anything you want. Log level runs from 0, for no logging, to 10, extreme logging. See man smbd.conf for the rest.

Save your changes and run

$ testparm

This checks smb.conf for syntax errors. Any errors must be corrected before going ahead. Then start up Samba:

# /etc/init.d/samba start

Finally, join your Samba machine to Active Directory:

# net ads join -U Administrator
Administrator's password:
Joined 'SAMBA1' to realm 'DOMAIN.NET.'

Hurrah! Success. The Samba box will now appear as a machine account under "Computers" in your AD console. Now stop Samba until the final steps are completed.

Enabling Windbind

Debian users may need to install the winbind package separately. RPM users will find it in the samba-common RPM. First, edit /etc/nsswitch.conf. The first three lines are the most important; the others vary according to your system:

passwd:

compat winbind

group:

compat winbind

shadow:

compat

hosts:

files dns wins

networks:

files dns

protocols:

db files

services:

db files

ethers:

db files

rpc:

db files

Save your changes, and fire up windbind and Samba:

# winbind
# /etc/init.d/samba start

Now verify that windbind is working. These commands pull lists of users and groups from the AD domain controller:

# wbinfo -u
BIGSERVER+Administrator
BIGSERVER+Guest
BIGSERVER+cschroder
BIGSERVER+mhall
# wbinfo -g
BIGSERVER+Domain Computers
BIGSERVER+Domain Admins
BIGSERVER+Domain Guests
BIGSERVER+Domain Users

This command verifies that logins and passwords are coming from the AD server, and not the local machine:

# getent passwd
BIGSERVER+cschroder:x:1000:1000:,,,:/home/BIGSERVER/cschroder:/bin/bash

If winbind is not working and local authentication is still active, they will not have the BIGSERVER+ prefix. Finally, as root run net ads info to display the AD server information.

Troubleshooting

If you've gotten this far and everything works, your Samba server is now a fully-fledged member of your Active Directory domain, and can be managed like any other AD object. A nice bonus is you may have local Linux accounts on the Samba box that are not visible in Active Directory; which means your Samba admins can SSH directly into the Samba server for admin chores, and not have to fuss with AD roadblocks.

A good troubleshooting guide is chapter 9 of "Samba-3 by Example" (Adding UNIX/LINUX Servers and Clients). Also refer to chapter 12 (Identity Mapping) of "The Official Samba-3 HOWTO and Reference Guide" to learn about winbind in greater depth.

 

Wednesday, February 11, 2009

A cool way to block internet access to certain users / machines

http://www.smart-x.com/?CategoryID=171&ArticleID=149

As a system administrator, you might find it useful to block internet access for certain users

and / or machine, but in many cases, you do want to allow access to several specific web sites.

This article shows an alternative way of doing it without using ISA, Firewall applications,

IPSec and other complex solutions.

The first thing you want to do is create a simple HTML document which says

'Internet access is forbidden… blah blah blah'.

You can use MS Word or simple Notepad to create such HTML file and save it somewhere

under the name 'Default.htm'.

The next step would be to publish this HTML document on one of your IIS servers.

You should use a dedicated web site which listens on some unused TCP port for this.

You can use any IIS server (or other OS) for publishing the HTML document.

However, I used IIS7 for enumerating the steps:

1. Create a folder on the IIS server and assign read access to the server's computer account

in the domain. (For example, if your server name is 'IISSRV01', assign to

http://www.smart-x.com/_uploads/imagesgallery/text1.jpgread permissions on the folder.

http://www.smart-x.com/_uploads/imagesgallery/pic1.jpg


2. Copy the 'default.htm' file you created to this directory.

3. Open Internet Information Services (IIS) manager (Shortcut: Start --> Run --> inetmgr)

4. On the left pane, Expand http://www.smart-x.com/_uploads/imagesgallery/text2.jpg.

5. Right click 'Sites' and choose 'Add new web site…'

a. Type 'InternetForbidden' in the 'Site Name' text box

b. Under the 'Physical Path' text box, type the path to the directory you copied
the 'default.htm' to.

c. Under the 'Port' text box, type any available TCP port number, higher than 1025.
For example: '8765'

http://www.smart-x.com/_uploads/imagesgallery/pic2.jpg

d. Click 'OK' to save the web site. If your newly added web site appears with a
red X next to it, click 'Sites' and the refresh display by using 'F5' keyboard key.
At this point, your new site should appear with a little 'Earth' icon, meaning
everything is fine.
e. In order to test your settings, try to browse to the web site by typing the
following address in the Internet Explorer Address bar of one of your
client machines: http://www.smart-x.com/_uploads/imagesgallery/text3.jpg
If everything worked fine by now, continue to the next stage.

The next stage would be to set this web site address as a proxy server for those
users / machines you want to restrict. There are many ways to apply these settings to clients.
In this article, I will go through the steps of configuring the proxy address through Group Policy.

1. Create a security group that will include all user / computer accounts which should be restricted.

2. Start Group Policy Management (Shortcut: Start --> Run --> GPMC.msc)

If you don't have GPMC installed, it is about time you install it! - http://www.microsoft.com/downloads/details.aspx?familyid=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en

3. On the left pane, select the OU which contain the user / computer accounts which you want
restrict.

4. Right click the selected OU and choose 'Create and link a GPO here…'

5. Type a name for the GPO and click 'OK'

http://www.smart-x.com/_uploads/imagesgallery/pic3.jpg

6. On the left pane, click on the newly created GPO.
7. On the lower part of the right pane, click the 'Authenticated Users' group
(under 'Security Filtering') and click 'Remove'. Click 'OK' to approve.
8. Click 'Add…' and browse to select the security group you created in the first step.

http://www.smart-x.com/_uploads/imagesgallery/pic4.jpg

9. On the left pane, right click the GPO and click 'Edit…'

10. On the left pane, Expand 'User Configuration' à 'Windows Settings' -->
'Internet Explorer Maintenance' --> 'Connections'

11. On the right pane, double click 'Proxy Settings'

12. Check 'Enable Proxy Settings'

13. In the 'Address of proxy' text box, type the address of the web site you created
at the beginning of the article. On the 'Port' text box, type the port of your web site
(In this example – 8765)

http://www.smart-x.com/_uploads/imagesgallery/pic5.jpg

14. If you have URLs of sites which should not be restricted, type the URLs in the
'Exceptions' list.

15. Click 'OK'

16. On the left pane, Expand 'Administrative Templates' --> 'Windows Components' -->
'Internet Explorer'.

17. On the right pane, double click 'Disable Changing proxy settings', change to 'Enabled'
and click 'OK'.

18. If you are restricting computer accounts (and not user accounts), meaning that the
OU you selected in step #3 contains the computer accounts and that the security
group you created in step #1 contains computer accounts, perform the following tasks:
a. On the left pane, Expand 'Computer Configuration' -->
'Administrative Tools' --> 'System' --> 'Group Policy'.
b. On the right pane, double click 'User Group Policy loopback processing mode',
choose 'Enabled', select 'Merge' and click 'OK'.
19. That's it! You can now close the Group Policy Object Editor and the
Group Policy Management Console and test your settings.
Note that group membership is updated at logon, so you will need your clients to log off
and back on in order to be restricted. If you are applying the GPO on a group of
computer accounts, the client computer should be restarted in order for the
computer account's group membership to be applied.

Why some applications malfunction when one of the Domain Controllers is down?

http://www.smart-x.com/?CategoryID=171&ArticleID=165

Why some applications malfunction when one of the Domain Controllers is down?
- Or -
How to switch to disaster recovery site without booting my clients

Every Sysadmin installs at least two Domain Controllers on his domain for redundancy and
fault tolerance. But what actually happens when one of the DC's is down?

If you do a simple and disconnect one of your DCs from the network, you'll see that about
half of the workstations and member server who hasn't booted since the DC is down are
experiencing problems such as sluggishness, performance issues and some of the
applications simply stop working. The reason for that is the way Netlogon works.

Netlogon is the process which is responsible, among other tasks, to detect Active Directory
environment and the closest DC. The detection process is called DC Locator.

It is implemented in the NetAPI.DLL in a function named dsGetDCName and invoked by the
Netlogon service when the service starts. The DC Locator process sends a request to all
Domain Controllers in the domain and waits for them to respond. Once responded,
Netlogon caches the Domain Controller who was first to respond and saves its details
in the cache. From that moment, every call made by any application for the dsGetDCName
function returns this DC.

The DC Locator process does not re-check the availability of the cached DC periodically..
Therefore, if this DC is gone for any reason, workstations and member servers who have already
cached this DC remain with the faulty cache until the workstation is rebooted. As a result,
any application that needs to access the DC (and call the dsGetDCName for it) receives the
faulted DC and is expected to have problems when trying to connect to it.

In the last years, fault tolerance became an essential requirement in many organizations.
Many enterprises implement expensive disaster recovery sites, buy expensive clusters and
replicate data to at least one additional location.

When the disaster does happen and the main site is going down, this limitation will cause
you lots of trouble until you reboot your entire organization.

Tuesday, February 10, 2009

Settings Windows Time on PDC emulator using w32tm

· Type the following command to configure the PDC emulator and then press ENTER:

w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update

where peers specifies the list of DNS names and/or IP addresses of the NTP time source that the PDC emulator synchronizes from. For example, you can specify time.windows.com. When specifying multiple peers, use a space as the delimiter and enclose them in quotation marks.

Then

w32tm /resync

Tuesday, January 27, 2009

WDS and server 2008 - WDS and DHCP on separate boxes.

NB: After installing WDS – REBOOT!!!!

 

http://www.infotechguyz.com/server2008/wds.html

 

 

Free system imaging solution ? Server 2008 Windows Deployment Services (WDS)?

Server 2008 Windows Deployment Services (WDS) replaces Remote
Installation Services (RIS) offered in Windows Server 2003 and 2000. WDS use PXE and TFTP to boot from WDS server.

The main difference between Windows Deployment Services (WDS) and other imaging solutions like Ghost is that WDS uses file-based imaging format where others use sector based. WIM format uses single instance store which files are stored only once and referenced multiple times. As result, images are a lot smaller.

Windows Deployment Services (WDS) supported OSes:
- Windows XP
- Windows Server 2003
- Windows Vista
- Windows Server 2008

 

How to install and configure Server 2008 Windows Deployment Services (WDS)

Server 2008 Windows Deployment Services (WDS) prerequisites

- WDS server must be a member server of an Active Directory domain
- DHCP must be configured for PXE boot to work
- DNS, you will mostly have this.
- OS media
- NTFS partition on the WDS server
- Server 2008

To install Windows Deployment Services (WDS) on Server 2008

open server manager > Click on Add Roles link > click Next > on the Select Server Roles screen, select Windows Deployment Services, and
then click Next.

On the Role Services screen, verify that Deployment Server and Transport
Server are checked; then click Next, then click Install

Start > Administrative Tools > Windows Deployment Services to access
the Windows Deployment Services Management console.
Choose the path to where images will stored.
Configure PXE Server settings, choose “Respond to all”, and Click finish.

Add a Boot Image to WDS Server

Boot image is the image file used during pre-installation OS, also known as boot OS and delivered via PXE boot.

1. Start > Administrative Tools > Windows Deployment Services to access
the Windows Deployment Services Management console
2. Right click the Boot Images node. Then click Add Boot Image
3. Click Browse to locate the boot image you wish to add. (Use the Boot.wim from the Windows Server 2008 installation DVD)
4. Once completed, you should be able to see this image you when perform a PXE boot.


Create a Capture Boot Image

Capture Boot Image is a boot image used when capturing images. You will use capture image to boot a server/client to capture its image into a .wim file. You can create a capture boot image by using the Boot.wim from the Windows Server 2008 installation DVD.

1. Start > Administrative Tools > Windows Deployment Services to access
the Windows Deployment Services Management console.
2. expand the Boot Images node
3. Right click the image you added earlier (See step 2 from Add a Boot Image to WDS Server)
4. Click Create Capture Boot Image
5. Once completed, click Finish.
6. Right click on boot image folder, choose "Add Boot Image"
7. Select the capture boot image we just created and click Next
8. Once completed, you should be able to use this boot image to capture Operating System images


Create an Install Image (create an image)

Install image includes the OS, custom applications and settings. It is most likely that you will have an install image for every OS you support.

1. Create a base computer (A computer that includes the OS, custom applications and settings).
2. Install sysprep.exe (If you are using windows 2003 or XP, you can find it deploy.cab of Installation CD,), note: sysprep is included by default in Server 2008
3. Run sysprep.exe on the base computer (on XP, sysprep –mini –reseal –forceshutdown )
4. Verify that the base computer is connected to the network and powered on the system
5. Perform a network boot (Often you can do this with the F12 key)
6. In the boot menu screen, select the capture boot image that you created earlier
7. Choose the source drive and enter a name and description for the image. Click Next. Note: only Sysprep drives will appear)
8. Choose "Browse" to select a destination for the image. Enter a name and click "Save", Select "Upload image to WDS Server"
9. Enter the name of the WDS server, and then click Connect.
10. Provide a user name and password if prompted
11. Select the "Image Group" from the list
12. Click "Finish"
13. Now, you should be able to install this image to a server/client via PXE boot.


Install an Install Image (restore an image)

This process restores the Install Image we created earlier.

1. Configure your BIOS to enable PXE boot (aka Network Boot)
2. Perform a network boot (usually by press F12)
3. Select the boot image from the boot menu.
4. WDS will load the computer into GUI and follow the wizard.

 

At the Datamail Group we value teamwork, respect, achievement, client focus, and courage.  This email with any attachments is confidential and may be subject to legal privilege.   If it is not intended for you please advise by replying immediately, destroy it and do not  copy, disclose or use it in any way.  The Datamail Group, through our GoGreen programme, is committed to environmental sustainability.   Help us in our efforts by not printing this email. __________________________________________________________________   This email has been scanned by the DMZGlobal Business Quality               Electronic Messaging Suite. Please see http://www.dmzglobal.com/dmzmessaging.htm for details. __________________________________________________________________  

Saturday, January 17, 2009

What should have been a joy became a disaster....

So I got myself a new monitor - A samsung 32" 1080p LCD (cost $150 NZD more than comparable 26" monitor after some strong negotiations so great option and the desktop real estate is HUGE!

Anyway, current ATI drivers for onboard chipset (790G) couldn't scale to 1080p, cue several frsutratiing hours of installing adn uninstalling latest ATI drivers (8.12) for Windows Server 2008 x64 (which is my 'PC' and HyperV host....you can see where this is heading...)

No dice, just cannot get the server to recognise the driver install

Desparate times so I rebuilt the system thinking HyperV's will easily restart with minimal fuss. Oh. No. They. Won't.

Monitor looks great now with older drivers off DVD that came with mobo so start VMs (discover you need to create NEW>Pick your old VHD file. All systems (including a DC started OK but weird things started happening - getting unauthenticated in the network centre, needing to rework the DC. End result was drop VMs from domain and re add.

Unfortunately on my Kerio mail server this blew away ALL my mail - could not find it at all.

Arrrgh!

After much googling found some help here:

http://jigar-mehta.blogspot.com/2008/02/how-do-i-extract-file-from-virtual-hard.html

Identified that I actually had snapshots (AVHD) of my mail server disk that were a lot bigger than the original VHD so using winimage was able to open these up and extract most of my email.

HyperV - you b@stard!

My fault I'm sure but you gotta learn somewhere the old adage, "There are 2 kinds of people in the world, those who backup and those who will backup"