Free ebook: Introducing Windows Server 2012

Microsoft Press have released a free ebook called Introducing Windows Server 2012, which does exactly what it says on the tin.

There are three versions available, depending on where you want to read it:

Introducing Windows Server 2012 RTM Edition – PDF ebook
Introducing Windows Server 2012 RTM Edition – ePub format
Introducing Windows Server 2012 RTM Edition – MOBI format

I read the version of this book that was based on the beta and found it very informative. It’s now been updated to the RTM version, so there’s no reason not to grab it now.

The Importance of Protecting AD Objects against accidental deletion

I’ve recently had to go through the process of restoring a series of OU objects which is not at all fun even with the AD Recycle Bin feature that came along with Windows Server 2008 R2.

It’s easy to make mistakes though but most can be averted with the ‘Protect Object from Accidental Deletion’ flag. In order to toggle this value in the ADUC console select View > Advanced Features.

Once selected the object tab is available which allows you to toggle the object.

Any OUs in the University Active Directory that have been created using the Server 2008/Vista or later AD tools will have the value set by default. Other objects such as users and computers do not get the value automatically.

If you would like to set the property on all OUs or all Objects in given OU then you can run the following commands using the Quest AD Commandlets with appropriate rights:

For OUs only

get-qadobject -sizelimit 0 -type OrganizationalUnit -SearchRoot "OU=MyOU,OU=Departments,DC=campus,DC=ncl,DC=ac,DC=uk" | Add-QADPermission -Deny -Account Everyone -ApplyTo ThisObjectOnly -Rights DeleteTree,Delete

For Computers Only

get-qadobject -sizelimit 0 -type OrganizationalUnit -SearchRoot "OU=MyOU,OU=Departments,DC=campus,DC=ncl,DC=ac,DC=uk" | Add-QADPermission -Deny -Account Everyone -ApplyTo ThisObjectOnly -Rights DeleteTree,Delete

For Everything

get-qadobject -sizelimit 0 -SearchRoot "OU=MyOU,OU=Departments,DC=campus,DC=ncl,DC=ac,DC=uk" | Add-QADPermission -Deny -Account Everyone -ApplyTo ThisObjectOnly -Rights DeleteTree,Delete

REMEMBER TO TEST YOUR SCRIPT FIRST!

Restoring permissions on an AD objects to Domain/Enterprise Administrators

I recently accidently set added Authenticated Users = Deny Read on GPO object. As ‘Deny’  ACEs take priority over ‘Allow’ everyone was blocked including Domain and Enterprise Administrators!

After some research, trial and error we found that the following procedure can be used to restore permissions back to Domain Administrators.

  1. Log on the PDC emulator as Domain Admin.
  2. Get the DN of the problem object(s)
  3. Run an elevated command prompt
  4. Run dsacls <dn> /R “DOMAIN\Domain Admins”
  5. Run dsacls <dn> /G “DOMAIN\Domain Admins”:GA
  6. Locate the system object in the AD. GPOs are in the System Container.
  7. Restore permissions for the object.
  8. Check the  object’s folder within SYSVOL and verify the permissions are up to date. If not then restore the permissions here too (I actually did this between 5  and 6 but according to Internet sources step 7 will do this).

Our Journey to the Cloud (Office 365): Part 2 – Technical Overview

This post outlines the technical steps on the road to implementing our Federated Office 365 with SSO and Exchange Hybrid Deployment. Each of these steps will be expanded upon in subsequent posts.

About Our Environment

Active Directory

Our Active Directory Forest consists of three Domains. An ‘empty’ Forest Root Domain fangorn.ncl.ac.uk (this was best practice when the Forest was created), a resource domain ‘campus.ncl.ac.uk’ which contains all objects used to manage the campus in Newcastle UK. There is also a third domain which is used to manage computer objects at our campus in Malaysia. For the purposes of deploying Office 365 we can ignore this last domain.

Our DNS namespace .ncl.ac.uk runs on a UNIX BIND system and domain controllers for the zones mentioned above have delegated authority for these subdomains. The Forest and all domains are running at Server 2008 R2 Functional level.

Mail

We run a mixture of Exchange 2007 SP2 and Exchange 2010 SP2 and are in the midst of migrating our staff and postgraduate research students to Exchange 2010.  Exchange 2007 remains on SP2 due to an incompatibility with a third-party archiving solution.  All Exchange servers are separated by role (CAS, HUB and MBX) and generally multiple instances for site-based resilience.  The Exchange Client Access infrastructure is fronted by a hardware load balancer.

Office 365 Tenancy Configuration

Configuring the Office 365 tenancy involved running the Office 365 deployment readiness tool and contacting Microsoft in order to have the tenancy located in the appropriate location relative to the number of users (size of the organisation). Another important step at this stage is proof of ‘ownership’.

Active Directory Federation Services Configuration

Federation of the Active Directory means that users can access services in Microsoft Office 365 using the existing Active Directory credentials (user name and password). Just as importantly this means we can use our existing User lifecycle, provision and access configuration tools to manage users using both cloud and on premises services.

The setup of Identity Federation and single sign-on (SSO) for Office 365 requires Active Directory Federation Services (AD FS).

Directory Synchronisation Configuration

The Microsoft Online Services Directory Synchronisation Tool (DirSync) establishes a one way synchronization from the on-premise Active Directory Forest (all domains) to Microsoft Online.

Dirsync is a requirement for running an Exchange Hybrid Deployment and allows global address list (GAL) synchronization from the on premises Microsoft Exchange Server environment to Microsoft Exchange Online.

Exchange Hybrid Deployment Configuration

An Exchange Hybrid Deployment refers to the full-featured deployment of a cross-premises Exchange messaging solution with Office 365 for enterprises and Exchange Online.

The features that an Exchange Hybrid Deployment delivers are:

  • Mail routing between on-premises and cloud-based organisations
  • Mail routing with a shared domain namespace. For example, both on-premises and cloud-based organisations use the University’s standard @newcastle.ac.uk SMTP domain.
  • A unified global address list, also called a “shared address book”
  • Free/busy and calendar sharing between on-premises and cloud-based organisations
  • Centralised control of mail flow. The on-premises organisation can control mail flow for the on-premises and cloud-based organisations.
  • A single Outlook Web App URL for both the on-premises and cloud-based organisations
  • The ability to move existing on-premises mailboxes to the cloud-based organisation
  • Centralised mailbox management using the on-premises Exchange Management Console (EMC)
  • Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organisations

Implementation

The team responsible for the implementation of Office 365 is the ISS Infrastructure Systems Group with our very own John Donaldson managing the project. A steering group with student representation provides strategic direction and sign-off.

Our broad testing and implementation strategy are the creation of two test environments followed by production.

POC Environment: A simple proof of concept comprising of a single domain with the minimal infrastructure required for to test the concepts of Federated Office 365 with SSO and Exchange Hybrid Deployment.

Full Test Environment: A fully virtualised environment which mimics (as closely as possible) our production environment. This environment will be maintained in tandem with the production environment and any future changes will be tested here first.

Windows Server 2012 Virtual Labs

When it releases later this year, Windows Server 2012 will bring a stack of exciting new features and enhancements, like the fantastic multi-server management features of the new Server Manager, and of course PowerShell v3.0!

If you want to get ahead of the curve on Server 2012, then there’s no better way that digging in and getting your hands dirty, although not everyone has a whole load of spare hardware to setup a test lab, and even if you do, then it’s sometimes difficult to know where to start, especially since pre-release software tends to be lacking some of the documentation that you might want to really explore a feature in depth.

To that end, Microsoft have produced a load of Windows Server “8” Beta Virtual Labs (put together before the Windows Server 2012 name was announced). These are self-contained modules focusing on the following:

  • Active Directory Deployment and Management Enhancements
  • Configuring a Highly Available iSCSI Target
  • Configuring Hyper-V over Highly Available SMB Storage
  • Implementing Storage Pools and Storage Spaces
  • Introduction to Windows PowerShell Fundamentals
  • What’s New in Windows PowerShell 3.0
  • Managing Branch Offices
  • Managing Network Infrastructure
  • Managing Your Network Infrastructure with IP Address Management
  • Managing Windows Server “8” with Server Manager and Windows PowerShell 3.0
  • Online Backup Service
  • Using Dynamic Addess Control to Automatically and Centrally Secure Data

In addition, you might want to check out some of the Resources for IT Professionals that Microsoft have published in relation to the TechEd conference that will start in a month in Orlando.

(Thanks to my friend @Alexandair for both of those links)

Office 365/ADFS 2.0: Forms AND Integrated Authentication (SSO) based on the user agent string

Background

The ADFS Farm + ADFS Proxy Farm model that we are using for Office 365 requires that the CNAME of the ADFS service has to be the same for both the ADFS proxy server farm and the internal ADFS farm (in our case adfs.ncl.ac.uk). Users ‘inside’ our network need to be directed to the internal farm and external users to the proxy farm.

ADFS supports multiple authentication mechanisms including the ones we are interested in, Windows Integrated Authentication (WIA) and Forms Based Authentication (FBA). It seems however that there is no way to dynamically select which one is used when a request hits the farm based on client properties. Where Office 365 is concerned a farm uses WIA or FBA

The way our network is configured means that we do not have the network model of Internal/DMZ/Internet with the split-brain DNS that the Microsoft documentation seems to expect. Our systems point at a single zone (running on BIND) which is resolves both internal and external requests.  As such, private IP addresses such as that of the internal ADFS Farm can be resolved (but obviously not connected to) from the Internet.

Working with our Network team we were able to get around this by creating a work around in BIND so that anyone on the Internet receives the address of the proxy farm and anyone coming from one of our internal IP ranges receives the address of the ADFS farm.

The problem for us is that only around 70% of our internal clients are domain joined and as such able to take part in SSO using WIA. The other devices may be non-Windows machines, non-domain joined Windows machines and mobile devices. Because they are coming from one of our internal address ranges they are directed to the internal WIA enabled ADFS farm and get a non-user friendly ugly pop-up box requesting authentication.

Authentication Popup

We do not think that this is a good user experience so we sought a solution which would let us provide both authentication methods to internal clients.

Possible solutions

After discussions internally and with Microsoft we were presented with 3 possible ways to deal with this problem.

  1. Our Network team could define every IP range we have and point them at the relevant BIND DNS view. This is obviously an inelegant solution and would not cover all scenarios as many ranges in our environment contain both domain joined and non-domain joined clients. It would however work for wireless guests as they are on specific ranges.
  2.  Microsoft proposed pushing out a HOSTS file to all domain joined clients pointing them at the internal farm. This not a scalable or suitable option in our environment as we have development work going on all over the University and this would essentially remove people’s ability to use the HOSTS file due to it being overwritten by whatever mechanism we would put in place to the job
  3. The third option was suggested by a Microsoft representative on the Office 365 community forums. The ADFS Farm could be configured to read a custom attribute from the browsers User agent string.This value would be parsed server-side and if present the request would be authenticated by WIA. Other requests would be forwarded on to FBA.  This was particularly attractive to us as we already use a custom user agent string value for Shibboleth authentication.

What we lacked was the expertise to implement this solution but thanks to collaboration with our colleagues as well as working with members of the Microsoft TechNet community we were able to implement something that seems to do the job for us. We thought we would share this in the event others are running in to the same problem!

Out of the Box Authentication with ADFS 2.0

The mechanism that is used by default on an ADFS farm or proxy Farm can be toggled in the <localAuthenticationTypes> element of the ADFS web.config

<microsoft.identityServer.web>
 <localAuthenticationTypes>
 <add name="Forms" page="FormsSignIn.aspx" />
 <add name="Integrated" page="auth/integrated/" />
 </localAuthenticationTypes>

For WIA ‘Integrated’ is at the top of the list:

<microsoft.identityServer.web>
 <localAuthenticationTypes>
 <add name="Integrated" page="auth/integrated/" />
 <add name="Forms" page="FormsSignIn.aspx" />
 </localAuthenticationTypes>

Implementing Selective Authentication using the user agent string

Manipulation of the User Agent string on Internet Explorer, Firefox and Chrome

The first thing required is to append the user agent string to browsers. This can be done in Internet explorer using Group Policy

  1. Under User Configuration expand Windows Settings/Internet Explorer Maintenance
  2. Select ‘Connection’
  3. In the right-hand pane, double-click User Agent String.
  4. On the User Agent String tab, select the ‘Customize String To be Appended To User Agent String check box
  5. Type in the string (in our case campus-ncl).

We have this value set in the ‘Default Domain Policy’ though it could be set lower down.

For Firefox and Chrome things have to be done in the application deployment package. Obviously people will have to use a managed version of the product as it’s not exactly a user friendly setup!

In Firefox the prefs.js file requires to extra lines:

user_pref("network.negotiate-auth.trusted-uris", "<ADFS FQDN>");
user_pref("general.useragent.override", ",<actual agent string> <customstring>")

So in our environment:

user_pref("network.negotiate-auth.trusted-uris", "adfs.ncl.ac.uk");
user_pref("general.useragent.override", ",<actual agent string> campus-ncl")

Chrome needs to be run with some extra switches:

--auth-server-whitelist="ADFS FQDN" --user-agent=" <actual agent string> + <customstring>

So in our environment

--auth-server-whitelist="adfs.ncl.ac.uk" --user-agent=" <actual agent string> + campus-ncl"

Disable Extended Protection must be disabled on the ADFS Farm in IIS (for Firefox and Chrome only)

In order to get SSO working with Firefox and Chrome Extended Protection must be disabled on the ADFS Farm in IIS. Lots of information on this feature and the consequences of disabling it can be found with a simple Google search.

ADFS Farm modifications

There are 2 steps required on the ADFS farm.

  1. Enable Forms Based Authentication as the default method.
  2. Modify the FormsSignIn.aspx.cs source code file

To turn on FBA edit the <localAuthenticationTypes> element of the ADFS web.config file and make sure FBA ‘Forms’ is at the top of the list:

<microsoft.identityServer.web>
 <localAuthenticationTypes>
 <add name="Forms" page="FormsSignIn.aspx" />
 <add name="Integrated" page="auth/integrated/" />
 </localAuthenticationTypes>

Next open the FormsSignIn.aspx.cs Source Code File.

The default out of the box, the code looks like this:

using System;

using Microsoft.IdentityServer.Web;
using Microsoft.IdentityServer.Web.UI;

public partial class FormsSignIn : FormsLoginPage
{
 protected void Page_Load( object sender, EventArgs e )
 {
 }
…

We need to add some code to the Page_Load event which will forward the request to integrated authentication if the campus-ncl user agent string is present. In order to do this we had to add System.Web to the namespace list.

using System;
using System.Web;
using Microsoft.IdentityServer.Web;
using Microsoft.IdentityServer.Web.UI;

System.Web supplies the classes that enable browser-server communication which are needed to get the user agent string and the query string generated by Microsoft Online Services.

protected void Page_Load( object sender, EventArgs e )
 {
 //Get the raw query String generated by Office 365
 int pos = Request.RawUrl.IndexOf('?');
 int len = Request.RawUrl.Length;
 string rawq = Request.RawUrl.Substring(pos + 1, len - pos - 1);

 //Convert query string (qs) to a string
 string qs = HttpUtility.ParseQueryString(rawq).ToString();

 //Get the user agent value
 string uagent = Request.UserAgent;

 //Check if the string campus-ncl appears in the User Agent
 //If it is there forward to WIA along with the Query String

 if(uagent.IndexOf("campus-ncl") > -1)
 {
 Response.Redirect("/adfs/ls/auth/integrated/?" + qs, true);
 }
 else
 {
 //Carry on and do Forms Based Authentication
 }
 }

And that’s it! Anyone using a managed browser with the custom string will be forwarded for WIA and get the SSO experience and all others will get FBA.

Things to note

  1. This method is not officially supported by Microsoft and there are potential issues around future ADFS upgrades (there is no guarantee that the same configuration will be in future versions of ADFS). We are also developing the fall back plan of pointing different clients and the different farms in DNS in case it is needed.
  2. There may very well be a better way to do this! If you find one please let us know 🙂

Special mention

Although we knew what we wanted to do we were having trouble getting the query string and putting it in a usable form (I’m not a programmer!) This information was provided by another TechNet forum member

 

Windows 7 now the most used OS on campus

It’s been a while since I did these stats, and I don’t think I’ve ever blogged them before, but I was prompted to check this after hearing Microsoft say that Windows 7 has overtaken previous versions worldwide.

It turns out that even though there hasn’t been any particular institutional drive towards Windows 7, thanks to the efforts of pro-active staff across the University, it does now significantly outnumber all other operating systems in our Active Directory combined! In the last 3 months, the breakdown of computers is…

Windows 7: 7155
Everything else: 5385

There are an unknown number of machines that aren’t connected to Active Directory, but the spread of those won’t affect this a great deal.

Another interesting stat that I heard recently came from Dell. They now predict that 50% of all server workloads are virtualised. Thats probably about true here – I’ll see if I can get those stats later.

Incidentally, the breakdown of Windows servers in our AD sees roughly equal numbers of Server 2008 R2 and Server 2003 (just over 200 of each), and just over a hundred running Server 2008.

If anyone is interested in grabbing these stats in their own organisation (or OU), then it’s just a simple bit of PowerShell using the Quest AD cmdlets

$computerObjects = Get-QADComputer `
-IncludedProperties pwdLastSet -SizeLimit 0
$recentComputers = $computerObjects | `
Where {$_.pwdLastSet -ge ((Get-Date).AddDays(-90))}
$recentComputers | Group OSName | `
Sort Count -Desc | Format-Table Count,Name -AutoSize

(That’s just 3 lines of code, but it could be fewer. The ` character extends the line in PowerShell)

Pre-staging Computers in Active Directory for WDS with PowerShell and Quest AD cmdlets

One of the most common issues when buidling computers with Windows Deployment Services (WDS, and RIS before that) are typos in the GUIDs used to net-boot the PCs. When you’re entering them by hand as you pre-stage the computer objects in Active Directory it’s very easy to make mistakes, especially when you’re entering a lot of them. It’s also extremely time consuming if you have to boot each machine to the point of PXE displaying the MAC and GUID – that’s why the smart move is to request that information from the supplier, preferably before they deliver the machines.

Anyone who has pre-staged a computer object before will be aware of the jiggery-pokery that goes on with switching round the first half of the GUID, so that when you view it later in ADUC, you see something significantly different to what you typed in. It appear that this conversion is done by the GUI when you create the object, so when you’re adding them programatically, you need to change the format yourself.

Microsoft published a VBScript function to reformat the GUIDs so they could be added to AD by a script, but I haven’t seen similar in PowerShell, so here it is:

function flip-guid ([string]$g) {
$g = $g.replace("-","").replace(" ","")
-join $g.substring(0,16).tochararray()[6,7,4,5,2,3,0,1,10,11,8,9,14,15,12,13] + $g.substring(16,16)
}

The function takes the GUID as a string and first removes any dashes or spaces (since I’ve received them from suppliers with both at different times). Next it converts the first half into an array of characters, selects them back in the new order and uses the join operator to make them back into a string, to which it concatenates the second half, unchanged from the original. As with most things in PowerShell it could be reduced down to a single line, or expanded further to enhance readability.

So, given the ability now to change the format, I use Quest’s AD cmdlets (if you haven’t come across these before, take a look now!) to create the computer objects. Assuming that you have a CSV file containing the new PC’s name and GUID, just do this…

Import-Csv newpcs.csv | foreach {
New-QADComputer $_.name -ParentContainer "SomeOU" -ObjectAttributes @{netbootguid = ([guid](flip-guid $_.guid)).ToByteArray()}
}

That’ll leave you with a load of new computer objects ready for WDS. 🙂

NB. It’s likely that the code snippets above have been wrapped to fit the page layout. In the function there are only two lines – everything from “-join” to the end is the same line. In the foreach scriptblock that’s just a single line.