Tagged: Active Directory

Office 365 – Lab 2 ADDS and AD FS 2.0

Lab 2


  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • SSL certificate signed by a public authority
  • Active Directory domain controller
  • Windows 7 client
  • Windows Server client (x 3) – in a production environment you should have 5
    • AD FS 2.0
    • AD FS 2.0 Proxy
    • Directory Sync Server
  • Enterprise Administrator credentials
  • Global administrator credentials with Office 365
  • Delegated write access to the Program Data container within ADDS (not required if you’re installing AD FS 2.0 using domain admin credentials)


The purpose of this lab is to simulate the implementation of true single sign-on with Office 365 using an Active Directory domain. This domain will be deployed with an internal sub domain of the company’s public domain name. See here on how to build an ADDS domain with a internal sub domain.

Lab Setup

Domain Controller

The domain controller should be built as per the guide here.

DirSync Server

The directory sync server should be built as per the guide here.

Federation Server

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name.

Computer Name: ADFS01

IP Address Gateway Primary DNS should be the IP address your DNS server is listening on. The IP Address has been bound to the network adapter for dedicated use by Federation services.


Join the computer to the domain.

Prerequisite Federation Server configuration

  • Create a internal DNS record for your federation server farm e.g. sts.domain.com
  • Create a service account for ADFS.
  • Install IIS 7.5 with defaults selected.
  • Generate a CSR for your public domain and install the certificate.

Create DNS record for Federation

Create a DNS record on the internal DNS. You’ll need to create a new zone for the public DNS zone e.g.


I’ve used sts as the host name for my Federation Server. If you also have public records for Exchange and Lync online etc. you’ll need to replicate those here.

ADFS Service Account

Create a normal domain user account to run the Federation Service.



Install IIS

Using server manager or Windows PowerShell install IIS using the defaults. The screenshots below are verification IIS is installed.



Install SSL Certificate

Generate a CSR for the public DNS name e.g sts.domain.name; obviously there will be content between the BEGIN and END certificate request.


Send the certificate to a certificate authority, once complete download the certificate and install it within IIS.


Install ADFS

First things first download the ADFS 2.0 installer from the Microsoft download center.


Run the installer and follow the install wizard.

Select Federation server


The installer will install the prerequisites if they haven’t already been installed.


When the installer is complete you’ll be prompted to run the configuration wizard.


Click finish then click the hyperlink below to follow the wizard.


Select the certificate SSL certificate installed earlier.


Select the user account you created earlier for the Federation service account.


When the installation and configuration is complete you’ll see lots of green ticks.


Install update rollup 1 for ADFS and reboot.


Optionally add another Federation server and configure network load balancing using Microsoft NLB or something similar. In my lab environment I didn’t but you can find more info here.

Verify ADFS is functioning by browsing to https://sts.domain.name/FederationMetadata/2007-06/FederationMetadata.xml


Federation Proxy Server

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name.

Computer Name: ADFSP01

IP Address (ideally this would be in the DMZ but in my lab I didn’t have the equipment available). The DNS servers assigned to this computer should be the public DNS servers provided by your ISP.


Do not join this computer to the domain.

Prerequisite Federation Proxy Server configuration

  • Configure the hosts file to point to the internal federation server.
  • Configure an external DNS record to point to the public address of your federation proxy.
  • Install IIS as per the installation on the Federation Server and import the  same SSL certificate; export the original to pfx first.

Configure DNS hosts file

Configure the local hosts to resolve sts.domain.name to the internal Federation server.


Create a external DNS record

Configure a public DNS record for the sts.domain.name which points to your Federation proxy; remember to point it to the public IP Address of the Federation proxy not the private 192.168. address.


Install IIS and SSL certificate

IIS should be installed as per the same process as the Federation server. To install the SSL certificate first export the certificate from the Federation server, ensure the export file type is a pfx file; remember the private key.

Install the pfx using the certificates MMC console ensuring you select the computer account.



Install ADFS

Copy the ADFSSetup.exe you downloaded for the Federation server installation to the Federation proxy.

Run setup and follow the install wizard.

Select Federation server proxy


Once the installation is complete click finish and update ADFS 2.0 to update rollup 1.


Configure the Federation server proxy using the configuration wizard.

Enter the Federation server when prompted and click test; if the connection is successful you’ll be prompted to enter credentials to establish a trust, use either the built-in administrator or the ADFS service account user.



To verify the Federation server proxy has been installed correctly look for event 198 in the ADFS 2.0 Eventing log.


Install the Windows Azure PowerShell modules on the Federation server; more info here.

Once the Azure modules are installed configure a trust between ADFS and Windows Azure AD using the following commands:

Provide the Office 365 credentials

$Cred = Get-Credential – this prompts you for your Office 365 credentials


Connect to Office 365

Connect-MsolService -Credential $Cred – Connect to Office 365 using the credentials specified above


Convert an existing domain or add a new one

Convert-MsolDomainToFederated -DomainName [domain name] – Converts a existing domain to a federated domain.


If the above command is successful a message similar to the one below will appear.


Verify Single sign-on

browse to http://login.microsoftonline.com

Enter your username Active Directory UPN e.g. username@domain.name.


When you tab to the password field Microsoft Azure will attempt to contact your Federation server e.g.


If your Federation or Federation proxy URL is not in your intranet trusted sites then you’ll be prompted for authentication. If you’re using a non-domain joined computer then you’ll be prompted for your credentials by the Federation server e.g. image below.


I also verified SSO using my mobile phones ActiveSync client.


I disconnected the network from the Federation proxy server and my mobile was unable to send emails, reconnecting the network allowed emails to be sent.


Email I attempted to send whilst the Federation proxy was offline


Post Installation considerations

The token signing certificate expires every 12 months; this is a self signed certificate used by the Federation server to sign all authentication tokens it issues. When the certificate expires on the Federation server you will need to update the trust with Azure. More info here.

The Directory sync server synchronises all Active Directory accounts. If you want to only allow specific users access to cloud services then you need to customise the incoming claim. See here.

Active Directory – Lab 1 ADDS with internal subdomain

The majority of Active Directory domains I have seen use a standalone internal domain such as .local, .internal or .company name.

When you suggest that the Active Directory domain should be a subdomain of the company’s public domain, you get the worried look that you’re exposing Active Directory to the internet… o_O.

If you take time to read Microsoft TechNet you’ll discover an article which details an internal subdomain of your public domain as the recommended way to deploy a DNS namespace, see here.

So If you’re building a new Active Directory domain then please feel free to follow the instructions details below.

Windows Server 2008 R2


  • Windows Server 2008 R2 media – download an evaluation from here
  • A static IPv4 address
  • Your internet providers DNS server IP addresses
  • A public DNS name registered with an applicable authority


Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address Gateway Primary DNS


Forest root domain FQDN: office.[public domain name]


Reboot when prompted

DNS Configuration

Create a reverse DNS zone for your local subnet.


Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable; this basically passes on the recursive DNS queries to your ISP rather than your DNS server. If root hints is left ticked then should your ISPs DNS servers be unavailable then your internal DNS will perform recursive DNS queries. Just FYI recursive DNS can be vulnerable to DOS attacks, cache poisoning and other issues commonly found when a DNS server is incorrectly configured.


Remove the root hints.


Testing DNS resolution using Network Monitor

Run Network monitor and scope the display filter to the DNS protocol, click start.

Because forwarding is enabled there are only two ethernet frames.


Initial query to my ISPs DNS servers.


Response from my ISPs DNS servers.


Office 365 – Lab 1 ADDS and DirSync

Lab 1


  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • Windows Server with ADDS installed
  • Windows 7 client
  • Windows Server client
  • Enterprise Administrator credentials
  • Global Administrator credentials


The purpose of this lab is to simulate the implementation of DirSync with Office 365 using an Active Directory domain which has been deployed with a non-public routable DNS domain name e.g. domain.local or domain.internal.

Once DirSync is synchronised with Office 365 then I’ll look at implementing Office 2013 on the Windows 7 client logging in as a domain user and observing the effects of DirSync and the password synchronisation feature.

Lab Setup

Domain Controller

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address Gateway Primary DNS


Forest root domain FQDN: office.local


The forest functional level needs to be at least Windows Server 2003.

reboot on completion.

DNS configuration

Create a reverse DNS zone for your local subnet.

Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable.

Remove the root hints.

Active Directory configuration

Using the Domains and Trusts snapin configure a publicly routable DNS name; this UPN must match your domain defined within the Office 365 portal.


Then configure all users who will be using Office 365 to use the public DNS name for their UPN; you can multi select.


DirSync Server

Install Windows Server 2008 R2, assign a static IP address, assign a suitable name and join to the domain.

Computer Name: MSOLDS01

IP Address Gateway Primary DNS


Join the computer to the office.local domain.

Install DirSync ensuring the prerequisite software is installed e.g. Microsoft .Net Framework 4.0.

DirSync configuration

Follow the wizard entering the global administrator username and password for your Office 365 environment.


Enter the username and password of an account with Enterprise Administrator membership.


Enable password synchronisation – http://technet.microsoft.com/en-us/library/dn246918.aspx. This enables the user to only remember one password; when the user changes their password within the on-premises ADDS the password will be synchronised within minutes.


Once you click finish you’ll be prompted to synchronise your ADDS with the cloud.


With password sync enabled the directory sync will result in the application event log recording verify Password Change Requests and Password Change Results for user accounts



You also notice event ID 650 and 651 recorded to signify that synchronisation has started and finished.

Once the directory synchronisation is complete you can verify within the Office 365 portal the last sync time and synchronised users.



Windows 7 Client

Install Windows 7, assign a suitable and name and join it to the domain. I’ve assumed DHCP is deployed so no need to configure an IP address.

Computer Name: Client01


Join the computer to the domain.

Client configuration

Logon to the client computer using your domain credentials e.g. jbloggs@UPN, login to the Office 365 portal and install Office 2013.


Open Outlook 2013 and follow the wizard, if your Active Directory properties do not have an email address defined as below then then Outlook auto-configure will not populate the Display Name, Email address etc.



Click next, If you have configured your DNS records as suggested by Microsoft e.g.


then Outlook will auto-configure itself too, you’ll be prompted for your Office 365 credentials as we are not using federated logins but because the password has been synchronised the password is the same as your Windows login credentials.


If you haven’t configured the autodiscover record correctly this step will fail; check out https://www.testexchangeconnectivity.com/ and select Outlook Autodiscover.


Outlook 2013 is now connected to Exchange Online


Securing Active Directory in a multitentant environment

Securing Active Directory

This article describes how to isolate Active Directory in an environment which is shared by many organisations or where departmental or business division administration is delegated.

Setting the Active Directory Access Mode

Using ADSIedit modify the dsHeuristics value to 001

ADSIedit > Configuration > Services > Windows NT > Directory Service > dsHeuristics > Properties > attribute value = 001

This setting allow you to define granular access control to objects within a container or OU to a particular group or user.

Setting the default security descriptor for a Organisational Unit

Using ADSIedit modify the defaultSecurityDescriptor for Organisational Units.

ADSIedit > Schema > Organisational-Unit > Properties > defaultSecurityDescriptor =


This removes the Authenticated Users Access Control Entry (ACE) from the new OU template.

Creating a OU hierarchy

This depends completely on the business but as an example you could have:

  • Domain
    • Business Departments
      • Service Groups
      • Finance
        • Service Groups
        • Users
        • Computers
      • Development Team
        • Service Groups
        • Users
        • Computers
    • Business Computer Infrastructure
      • Backup Servers
      • Deployment Servers
      • Service Groups
        • Groups
      • Users

This above hierarchy will make sense later on in the article.

Securing the default containers

The following containers will be viewable by all users i.e.  Authenticated Users unless you remove the Authenticated Users ACE.

  • Builtin
  • Computers
  • Domain Controllers
  • Users

Creating groups for delegation of Administration and other Active Directory functionality

The following groups are required to ensure the OU hierarchy defined above works i.e. users can read group policies, delegated administrators can create users, change passwords etc.

  • Business Departments/Service Groups
    • g_allAdminsGroup@yourCompany
    • g_allUsersGroup@yourCompany
  • Business Departments/…/Service Groups
    • g_Allusers@DepartmentName
    • g_Admins@DepartmentName
    • g_Users@DepartmentName
    • g_ServiceUsers@DepartmentName
    • dl_ComputerAdministrators@DepartmentName
    • dl_RemoteDesktopUsers@DepartmentName
  • Business Computer Infrastructure/Service Groups/Groups
    • g_CompanyAdministators (Level 1)
    • g_CompanyAdministrators (Level 2)
    • g_CompanyAdministrators (Level 3)
    • dl_BackupServerOperators
    • dl_BusinessComputerInfrastructureAdmins
    • dl_BusinessAdministrators
    • dl_EnterpriseAdministrators

Creating a group membership strategy

The following group membership strategy utilises the groups created above to create a secure Active Directory environment.

  • g_AllUsers@DepartmentName
    • Member Of:
      • g_AllUsersGroup@yourCompany
    • Members:
      • g_Users@DepartmentName
      • g_Admins@DepartmentName
      • g_ServiceUsers@DepartmentName
  • g_Admins@DepartmentName
    • Member Of:
      • dl_ComputerAdministrators@DepartmentName
  • g_AllAdminsGroup@yourCompany
    • Member Of:
      • g_AllUsersGroup@yourCompany
    • Members:
      • g_CompanyAdministrators (Level 3)
  • g_CompanyAdministrators (Level 3)
    • Member Of:
      • dl_BusinessAdministrators
      • dl_BackupServerOperators
    • Members:
      • g_CompanyAdministrators (Level 2)
  • g_CompanyAdministrators (Level 2)
    • Member Of:
    • Members:
      • g_CompanyAdministrators (Level 1)
      • Member Of:
        • dl_BusinessComputerInfrastrucutreAdmins
        • dl_EnterpriseAdministrators
      • Members:

The group membership strategy basically has g_CompanyAdministrators (Level 1) as the senior administrators for the enterprise, g_CompanyAdministrators (Level 2) and (Level 3) would be administrators and juniors. The enterprise administrators (senior to junior) could have access to the business divisions or departmental administrators hierarchy for support etc.

Creating a user membership strategy

Departmental or business division users would be members of g_Users@DepartmentName, delegated administrators would be members of g_Admins@DepartmentName.

I have defined a group called g_ServiceUsers@DepartmentName this would be used for service users specific to that department e.g. Microsoft SQL server for the development team or users that run scheduled tasks.

The departmental computers would be members of domain computers by default but would also be a member of g_AllUsers@DepartmentName.

Securing departmental organisational units and delegating administration

Assign the group g_AllUsersGroup@yourCompany read permission (this object only) on the Business Departments OU.

Assign the group g_AllUsers@DepartmentName read permission (this object and all child objects) on the respective department OU.

Assign the group g_Admins@DepartmentName create / delete group objects, create / delete user objects (this object and all child objects) and full control (group and user objects) on the respective department OU.

(if enterprise administrators support departmental administrators  delegate these privileges) Assign the group g_AllAdminsGroup@yourCompany list contents, list object, read all properties, write all properties, read permissions, modify permissions, all validated writes, all extended writes and create all child objects (this object and all child objects) on the Business Departments OU.

Group Policy Management delegation

Template policies

A number of template policies would be required. The most important one would determine the local computer membership and users rights for a particular department e.g.

Computer Configuration/Windows Settings/Security Settings/Restricted Groups/

  • Administrators
    • dl_BusinessAdministrators
    • dl_ComputerAdministrators@DepartmentName

You may also configure the Remote Desktop Users group, if depends on how you would support the departmental users. In that scenario it would be wise to determine who can logon via Remote Desktop Services using Group or Local policy

Computer Configuration/Windows Settings/Local Policies/User Right Assignment/

  • Allow log on through Remote Desktop Services
    • dl_RemoteDesktopUsers@DepartmentName
    • dl_BusinessAdministrators
    • dl_ComputerAdministrators@DepartmentName

Policy delegation

Below are some example group policy delegation permissions e.g. the enterprise administrators are allowed to link existing GPOs to the Business Departments OUs, juniors enterprise administrators are allow to editing existing GPOs as are enterprise administrator but juniors cannot link them; think peer review of GPOs.

Linking GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Business Departments/

Select the delegation tab and assign the ‘link’ permission to g_CompanyAdministrators (Level 2)

Editing GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Group Policy Objects/templatePolicy1

Select the delegation tab and assign the ‘edit settings’ permission to g_CompanyAdministrators (Level 3)

Creating GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Group Policy Objects

Select the delegation tab and assign the ‘add’ permission to g_CompanyAdministrators (Level 1)

You could also deploy something similar at the Business Department level so departmental adminstrators could link specific policies.