Active Directory

AADConnect

Recently I faced an issue with Azure AD Connect.

The scenario:

A Windows Server 2012 R2 box with direct access to the internet with Azure AD Connect installed and running under the context of a service account.

As Azure AD Connect was running in the context of a service account, it wanted to utilise a proxy server to connect to the internet as it is WPAD aware.

The error message given was:

An error occurred executing Configure AAD Sync task: user_realm_discovery_failed: User Realm Discovery Failed

The trace log file also reported:

Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required.

All the solutions (AADConnect Troubleshooting) I found on the internet pointed me at configuring the machine.config (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config) with the required proxy server settings, but in my scenario I did not want to utilise a proxy server.

To resolve the issue I added the syntax below to the machine.config file which resolved the issue.

<system.net>
                <defaultProxy enabled=”false”></defaultProxy>
 </system.net>

As always test in your environment before deploying into production.

AADConnect Troubleshooting – https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect-troubleshoot-connectivity/ (Accessed 16/05/2016)

 

 

 

nitialize-ADSyncDomainJoinedComputerSync

Azure Active Directory Connect (AADConnect) is the tool that connects your on-premises Active Directory to Azure Active Directory.

At the end of the setup there is a rather unhelpful message asking you to run

AdSyncPrep:Initialize-ADSyncDomainJoinedComputerSync

Translated to English this means. (also see Update 20/07/2016)

  1. Open PowerShell and set your execution policy to unrestricted.
    set-executionpolicy unrestricted

  2. Change directory to
    C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep

  3. Then
    import-module .\AdSyncPrep.psm1

  4. Then
    Initialize-ADSyncDomainJoinedComputerSync

  5. Supply values for the following parameters:

    AdConnectorAccount: your AAD connector account.
    i.e.identitatem\svc_aadconnect@identityproject.co.uk

    AzureADCredentials: your credentials for Azure.
    logon@identityproject.co.uk

  6. If successful you should see
    Initializing your Active Directory forest to sync Windows 10 domain joined computers to Azure AD.Configuration Complete

  7. As good practice, set  your execution policy back to restricted.
    set-executionpolicy restricted

Update 20/07/2016:

This must be run from a computer that has the Active Directory module for Windows PowerShell and the AD DS Snap-Ins and Command-Line Tools installed.

Tooling

Failure to have both options installed will result in two errors:

The first error is obvious.

ADSyncPrepError

The second is not quite so obvious, a dsacls.exe error is generated as the command line tooling is not installed.

DSAcls Error

 

 

 

I am once again honoured to be a recipient of the Microsoft MVP award for Directory Services.

Since first becoming an MVP in 2009, the Directory Services designation has evolved to cover many complimentary technologies and solutions in both on-premises and cloud solutions, such as traditional Active Directory to Azure Active Directory.  Microsoft’s rate of innovation and change within the Azure space alone is phenomenal and shows no sign of abating and  whilst these new technologies are exciting they have to be learnt and understood in order to implement and support the adoption of these new technologies.

The book I am currently reading “Rookie Smarts” by Liz Wiseman highlights an interesting research analysis, in the book Liz states that.

Knowledge decay in the 1970’s was 10% per annum” but “In 2005 it was estimated that knowledge becomes obsolete at 15% per year, but in high tech this is as much as 30%.   If information doubles every 9 months and decays at 30% a year; within 5 years, only 15% of your knowledge will be relevant”.

If I want to keep being awarded the MVP designation, it’s obvious (well to me anyway) that I need to keep up with the technology (as well as supporting the community), else my skills will soon be as relevant as my MCSE in NT 3.51.

It never fails to amaze me how ones words and actions can directly and indirectly influence another person’s actions or even alter their career path.  Over the years I have always tried to share my knowledge with my peers and the IT community as a whole and yesterday I felt rather humbled to receive this comment in an email.

This is my first full time AD role. I find it funny you ask [sic. an irrelevant question], you’re indirectly responsible for me getting this job.  I followed your work for years, so thank you.

It’s the little things that make a big difference.

This summary stems from a brief conversation within a peer circle. A parallax perspective on the issue of passwords. 

Most IT organisations have an IT Security policy, which defines the required password parameters for an organisation.  Active Directory provides a method to enforce the password parameters, from their complexity and length to the frequency that they must be changed. 

Once a company’s password policy is understood and required parameters are known, internally bad practice can set in and this is not necessarily limited to the end users, IT can equally be at fault.  For example the service desk may create all new user or service accounts with the same common password.  Password1234$$ or Welcome2015! 

So what has this got to do with hacking your own Active Directory? 

Using one of the numerous Active Directory password cracking tools on the internet, you can analyse (crack the easy ones) the passwords stored in Active Directory and produce a list of the most common passwords.

These common passwords can then be cross referenced to their owners and with a little bit of mathematics, it is possible to deduce that perhaps with 10 passwords, 70 % of all systems can be accessed, not only is this a rather frightening metric, but this is reality and one attack vector for anyone with access to a domain controller. 

This is not a simple problem to fix with the current architecture of Active Directory, but with small process changes and education around the use of common passwords the percentage of systems that could be accessed or compromised may be reduced. 

 

The Microsoft MVP summit was held last week (3rd – 7th November) in Redmond, where I had the good fortune to spend the week with members of various Microsoft product teams that are responsible for what we commonly know as Active Directory.  I can genuinely say that in technology terms I have not been this interested in the future of Windows since I did my first Windows Server 2000 course (MOC 1561) back  in 1999.

The MVP Summit content is mostly under NDA and I have always respected the NDA and with this in mind all I will say is that over the next few months I will be reading and learning as much as I can on the following areas of Microsoft technology.

Azure Active Directory

Azure Active Directory Sync Services

Azure Rights Management

Windows 10

I would also recommend that you start to start to think about the concept of Active Directory being an identity provider and that in the future it will all be about managing identities and not solely about managing the technologies that deliver them.

Food for thought, think about what type of identities your business will support, business only or perhaps personal too? What is an identity? What is a personal identity? Who owns the identity?  (I will follow up on this concept with another post).