[Windows Azure AD] WAAD whitepapers updated

Microsoft has updated its series of whitepapers on Windows Azure AD.

This series of whitepapers on Windows Azure AD offerings comprises:

• Active Directory from the on-premises to the cloud whitepaper.
• An overview of Windows Azure AD
• Leverage Multi-Factor Authentication with Windows Azure AD whitepaper.
• Leverage Multi-Factor Authentication Server on your premises whitepaper
• Leverage Windows Azure AD for modern Business Applications whitepaper.

An overview of Windows Azure AD whitepaper introduces the trends that sustains a new identity model, the role of Identity Management as a Service (IdMaaS) and presents in this context the Microsoft’s identity offerings in the hybrid era.
An introduction on Windows Azure AD whitepaper further presents the capabilities that can be leveraged to centralize the identity management needs of your modern business applications, and your SaaS subscriptions, whether they are cloud-based, hybrid, or even on-premises. Windows Azure AD is a complete offering that can help you take advantage of your on-premises existing investment, fully outsource to the cloud your users (and devices) management and anything in between.

For enterprises with more demanding needs an advanced offering, Windows Azure Active Directory Premium, currently in preview, helps complete the set of capabilities that this identity and access management solution delivers.

Leverage Multi-Factor Authentication with Windows Azure AD whitepaper covers the Windows Azure Multi-Factor Authentication paid offering and how to leverage it with Windows Azure AD (Premium).

As an addition, Leverage Multi-Factor Authentication Server on your premises whitepaper describes how to use Windows Azure Multi-Factor Authentication Server and to configure it to secure cloud resources such as Office 365 so that so that federated users will be prompted to set up additional verification the next time they sign in on-premises.
In order to streamline and to ease as much as possible the way to build a suitable test lab environment for such a multi-products and services solution, this whitepaper leverages the Windows Azure environment along with the Windows Azure PowerShell cmdlets to build the on-premises test lab environment to test and evaluate the Multi-Factor Authentication Server.
The eponym archive file contains the script New-TestLabEnvironment.ps1 referred in the whitepaper for building the "on-premises" test lab environment. This script illustrates how to leverage the remote Windows PowerShell capabilities along with the Windows Server automation with Windows PowerShell to setup the required virtual machines.

Leverage Windows Azure AD for modern Business Applications whitepaper further presents the aspects that relates to the development of solutions. Windows Azure AD offers to developers and cloud ISVs an identity management platform to deliver access control to their modern business applications, based on centralized policy and rules. 

Whitepapers are available here : Active Directory from on-premises to the cloud – Windows Azure AD whitepapers

[Security] Special edition of the Microsoft Security Intelligence Report published

Microsoft has published a special edition of the Microsoft Security Intelligence Report entitled "The Cybersecurity Risk Paradox: Impact of Social, Economic, and Technological Factors on Rates of Malware".

For more informations, check the following blog posts:

• New report outlines cybersecurity challenges in developing countries
• The Cybersecurity Risk Paradox: Measuring the Impact of Social, Economic, and Technological Factors on Cybersecurity

The document is available here : The Cybersecurity Risk Paradox: Measuring the Impact of Social, Economic, and Technological Factors on Cybersecurity

[Windows Azure AD] New Test Lab Guides

Microsoft has publish two new test lab guides For Windows Azure AD.

The first is entitled "Creating a Windows Azure AD and Windows Server AD Environment using DirSync with Password Sync" and the second, "Creating a Windows Azure AD and Windows Server AD Environment with Federation (SSO)"


The documents are available here :

• Creating a Windows Azure AD and Windows Server AD Environment using DirSync with Password Sync
• Creating a Windows Azure AD and Windows Server AD Environment with Federation (SSO)

[Active Directory] How many Infrastructure Masters do you think you have in your forest ? Part 1

Well, maybe you think it's not an expert question, everybody knows about FSMO role holders. 

FSMO in brief :

Active Directory Domain Services defines five operations master roles: the schema master, domain naming master, RID master, PDC emulator, and infrastructure master.

The five operations master roles are assigned automatically when the first domain controller in a given domain is created. Two forest-level roles are assigned to the first domain controller created in a forest and three domain-level roles are assigned to the first domain controller created in a domain.

The schema master and domain naming master are forestwide roles, meaning that there is only one schema master and one domain naming master in the entire forest.
The other operations master roles are domainwide roles, meaning that each domain in a forest has its own RID master, PDC emulator, and infrastructure master.

For more informations about FSMO : Operations Masters Technical Reference


So, if I ask  how many Infrastructure Masters do you think you have in your forest ?
Well, your answer should be naturally : One for each domain !

Obviously, if I ask this question it's that maybe not the correct answer.
Your answer should be : It depends !

Before going further, we have to talk about Active Directory partitions.

Active Directory partitions in brief :

 The Active Directory database is logically separated into directory partitions:

• Configuration partition
• Schema partition
• Domain partition

 
Configuration  Partition :  Contains the Configuration container, which stores configuration objects for the entire forest in cn=configuration,dc= forestRootDomain . Updates to this container are replicated to all domain controllers in the forest.

Schema  Partition :  Contains the Schema container, which stores class and attribute definitions for all existing and possible Active Directory objects in cn=schema,cn=configuration,dc= forestRootDomain . Updates to this container are replicated to all domain controllers in the forest.

Domain Partition : Contains a < domain > container, which stores users, computers, groups, and other objects for a specific Windows 2000 domain. Updates to the < domain > container are replicated to only domain controllers within the domain and to Global Catalog servers if the update is made to an attribute that is marked for replication to the Global Catalog.

Windows Server 2003 introduces a new type of partition : Application directory partitions 

An application directory partition is a directory partition that is replicated only to specific domain controllers. Application directory partitions are usually created by the applications that will use them to store and replicate data. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. Application directory partitions can contain any type of object, except security principals.  

If your DNS is integrated in Active Directory, you have two application partitions for DNS zones : ForestDNSZones and DomainDNSZones.

For more informations about Directory Partitions : Directory Partitions  and Application directory partitions

Maybe you ask yourself why we are talking about Directory partitions ?

Because there is one Infrastructure Master for each Application directory partition.

So you've got the answer !
How many Infrastructure Masters do you think you have in your forest ?
One for each domain + one for each Application directory partition.

For exemple if I have a forest with 3 domains with IAD DNS, I have 7 Infrastructure Masters.

• 3 for each Domain
• 1 for the ForestDNSZones
• 3 for the DomainDNSZones

How can you check that ?

I've build the following lab :

• One Forest with Three Domains with IAD DNS :
• ROOT.ADDS
• CHILD1.ROOT.ADDS
• CHILD2.ROOT.ADDS

First we'll see how you can view Application partitions.
That's really easy with Powershell :

Import-Module ActiveDirectory
Get-ADForest

You can also use dsquery :

 dsquery * "CN=CONFIGURATION,DC=ROOT,DC=ADDS" -filter "(systemflags=5)" -attr ncname 

So we've got the ncname for our four Application partitions but that's not enough to find their Infrastructure Master.
For that we need the following attribute : ms-DS-NC-Replica-Locations

To retrieve this attribute we can use the following cmdlet:

Get-ADObject -Filter {systemFlags -eq 5} -SearchBase ((Get-adforest).PartitionsContainer) -properties msDS-NC-Replica-Locations,ncname | fl

So now we also know for every Application partitions which domain controllers have a replica of the Application partition.
You have probably noticed that it's an array composed of the distinguished name of the nTDSDSA object of each Domain Controller which have a replica of the Application partition.

With this information we can't retrieve the Infrastructure Master of each Application partitions directly but with the distinguished name of the nTDSDSA object we can retrieve the DNS name of the domain controller.

Here is the script :

Import-Module ActiveDirectory
Get-ADObject -Filter {systemFlags -eq 5} -SearchBase ((Get-adforest).PartitionsContainer) -properties msDS-NC-Replica-Locations,ncname|%{
$nTDSDSADN=$_.'msDS-NC-Replica-Locations'[0]
$Server=$nTDSDSADN.Replace("CN=NTDS Settings,","")
$DC = Get-adobject $Server -Properties dNSHostName
Get-ADObject -SearchBase $_.ncname -filter {objectclass -eq "infrastructureUpdate"} -properties objectclass,fsmoroleowner -server $DC.dNSHostName | select DistinguishedName, ObjectClass, FSMORoleOwner}|fl

As you can see we now have retrieve the information and we know which domain controller is the Infrastructure Master for each Application partitions.

I hope you've learn something in this post.
We'll see in the next part why it could be important to check that attribute.