Microsoft Graph accessing Azure AD to Create a User

22 May 2019

The scenario is relatively simple, I want to programmatically create a new user in the Azure Active Directory (AD). I wanted to use the Graph API that Microsoft has developed, from what I read it should be straight forward. Unfortunately, there were a lot more twists and turns in this journey than I had planned so thought the right thing to do was to write it down for others to hopefully have an easier learning process.

As with all learning there was a lot of google searching involved, I have tried to capture the resources that were helpful to give them recognition for their help.

One of my first obstacles was including the right libraries, as most of the code samples failed to include the using statements that they required. The libraries that I ended up using were as follows:

using Microsoft.Toolkit.Services.MicrosoftGraph;
using Microsoft.Graph;
using Microsoft.Identity;
using Microsoft.IdentityModel.Clients.ActiveDirectory;

This Stack Overflow question [1] was the most useful code on connecting to the Active Directory and access the user objects. The magic values that you need are fairly straight forward but are detailed as follows.

First thing you need to make sure that you do is to create and Application Registration in Azure Active Directory. You need this to get your Client ID and Tenent ID that you need so your code so it can connect to AD.

The next obstacle was the Client Secret that had me stumped for a while. This comes under Certificates and Secrets within the AD Admin Portal. You just need to create a new Secret and grab the value it creates.

They are all the magic values you need to be able to connect to the Azure AD. Only problem now is that security is turned off by default. Within the Azure AD Portal under the API Permissions you need to make sure that Microsoft Graph is there and that it has the necessary permission depending on what actions you need to perform.

Create User

Brian Jackett’s blog post [2] was helpful for giving a good context to tackle this and gave hints as to permission etc.

If you have been following along diligently you will have some code that can read the users in your Active Directory. The document, that I actually started with on the journey was the Microsoft Graph Documentation on how to Create a User with the Graph API [3]. Having back tracked and done all the steps I have documented above you can now use this code to create your user in AD.

That is it in a nut shell, follow these easy steps at you will be able to access your Azure AD and create and read users from it.

Thanks for reading I hope you found it helpful.



[1] Stack Overflow:

[2] Blog post by Brian Jackett:

[3] Microsoft Graph Documentation to Create User :



Which System?

22 April 2014

As a follow on from my post on reference architecture you can start to look at what system(s) deliver these functions. Most often there are multiple systems that deliver a certain function within an organisation. There are multiple historical reasons that cause this to happen, one of the most common ones is organisation structures that drive two areas of the business to implement their own systems to solve a similar problem. There are many more, the key is that that would have made sense at the time.

As the organisation looks at the business and such things of the cost of running the organisation and the ability to respond to change duplication is detrimental to this. If you have 2 or more systems broadly delivering the same function you firstly have duplicated costs across these systems. Also if you need to make a change to a function across the organisation then you will need to change all systems that perform this function, reducing your ability to respond quickly i.e. time to market.

Reference Architecture - Which System

In the diagram above you will note that the non-strategic systems can often be categorised in some way. The spreadsheet system is red or bad, as in get of it as soon as you can. The orange coloured systems are not strategic systems but staying on them is less detrimental to the organisation than the spreadsheet solution. How organisations deal with these classifications are many and varied.

The enterprise will often look at these functions and set a direction or target state for this function. E.g. we will move to a Strategic system that meets the requirements of the enterprise as a whole. You end up with a system that is deemed strategic. If a project is impacting this function from an architecture perspective the project should remove the function from the non-strategic (Legacy) system and implement it in the strategic system.

The big problem here is that a small project may be planning to implement a 100k solution but the cost to move to the strategic system may blow the cost out to many millions of dollars. Here we have to deal with trade-offs, architecturally we should be going in one direction but project pressures (cost) mean we may need to actually do some development in the nonstrategic system.

This now goes into the realm of architecture governance which I may skip at this point.

So as a solution architect you have a target state for in this case “Loan Origination” being the Strategic Lending System. You need to weigh up your projects ability to say move part or all of the origination function out of the Retail Lending System. This becomes a transition state and with all journeys you may need to back track a little to actually get to your destination or invest in a non-strategic system.

It is up to you to sell this to your stakeholders.

Reference Architecture

22 April 2014

In some cases an organisation has been utilising various IT systems over the past 30 years. As business problems evolve the IT systems will change and in some cases new ones will be added. Over these sorts of period of time a fairly chaotic environment can eventuate creating complexity and subsequently an inefficient architecture.

This complexity usually manifests itself in preventing or slowing down the businesses ability to respond to change in the market. Back in the day the business would be talking to the Chief Architect telling him they had to be able to sell on the internet. The problem was that their system wouldn’t be architected to support the volumes the internet would provide and most likely the thick client wasn’t suited to the internet. Sound familiar.

You find that an organisation will often produce a reference architecture that is designed to provide some guidance on how future solutions should be developed to reduce the complexity. Think along the lines of a council implementing various building regulations.

Reference Architectures take various forms but as a starting point try and break the functions delivered by technology into some logical categories. Here I have taken part of the Microsoft Reference Architecture for Banking.

Reference Architecture - Banking

The fun starts when you take a reference architecture like this and overlay the systems in use over the top of this. You often find that a function is duplicated across multiple systems and that a system is performing multiple functions which limit the ability to reuse.

So all the good coding practices that we learn as developers get violated when we look at the architecture of the enterprise. So in a sort of way we need to do a little refactoring.

So starts the journey of many transition states to get to our target state……..

Four stages of competence

4 April 2014

The learning model that has been the most use to me has been the Four stages of competence. I think part of the reason I like it is I find a bit of humour in calling myself incompetent. I am a bit of a Highlander fan and when I hear the word incompetent I remember this scene from the movie:

Tony the Hotdog Vendor: [as Tony reads a newspaper headlined: Headhunter-3, Cops-Zero] Hey Moran! Have you read what it says in here?

Lieutenant Frank Moran: You kiddin’ Tony? You know cops can’t read.

Tony the Hotdog Vendor: [Teasingly to Moran] What does ‘INCOMPETENT’ mean?

Movie trivia aside.

To learn you have to acknowledge that you don’t know something. At this point you are moving from Unconsciously Incompetent to Consciously Incompetent. This can be the hardest step for some people but is critical to start the learning process off. As a mentor this is one of my big challenges. Thankfully I often draw the Four stages of competence matrix and call out there is a long list of things in the unconsciously incompetent quadrant that they just don’t know about.

Four Stages of Competence

and so starts the learning process from there.

I hope you find it as useful as I do.

Are we there yet?

24 December 2013

For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.

Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.

Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.

Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.


This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.

This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:

  1. Unknowns that I have discovered (Known Unknowns)
  2. A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)

Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.

Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.

Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things

  1. You either do some more investigating and identify the unknown
  2. Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.

So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.

Good Luck!

On “Geek” Versus “Nerd”

30 July 2013


To many people, “geek” and “nerd” are synonyms, but in fact they are a little different. Consider the phrase “sports geek” — an occasional substitute for “jock” and perhaps the arch-rival of a “nerd” in high-school folklore. If “geek” and “nerd” are synonyms, then “sports geek” might be an oxymoron. (Furthermore, “sports nerd” either doesn’t compute or means something else.)

In my mind, “geek” and “nerd” are related, but capture different dimensions of an intense dedication to a subject:

  • geek – An enthusiast of a particular topic or field. Geeks are “collection” oriented, gathering facts and mementos related to their subject of interest. They are obsessed with the newest, coolest, trendiest things that their subject has to offer.
  • nerd – A studious intellectual, although again of a particular topic or field. Nerds are “achievement” oriented, and focus their efforts on acquiring knowledge and skill over trivia and memorabilia.

Or, to…

View original post 1,308 more words


30 July 2013

I hope I haven’t had this impact on the people I have mentored?



Project Management Triangle

30 July 2013

The Project Management Triangle is one of my favourite models that I find myself drawing on many occasions. As an architect you are constantly having scope discussions and while at an architecture level it may be OK it impacts time and/or budget which may not be satisfactory. This is a simple and effective way to explain why:

Project Management Triangle

Collecting Questions

18 February 2013

I posted previously about the benefit of an Architecture On A Page and the benefit that it provides as an architect. Being able to socialise an architecture is an important part of the job of an Architect. You socialise your architecture so that you can understand that different people’s wants of the final design are. A tester will have a different perspective to the asset manager who will need to support the application.
These conversations and the resulting requirements, constraints etc are what my maths teacher used to refer to as my working out. Much like I needed to show my working out to a maths question it is important to show your working out to an architecture. This working out presents to people the different ways you have looked at your design and takes them down the journey you have been on to discount options and refine the architecture.
Unfortunately there is never a “perfect” architecture; it is always a set of tradeoffs that need to be made. Your ability as an Architect to make your design as good as you can and also your ability to communicate this design is driven by the completeness and accuracy of the considerations you have made with regards to the architecture.
To build this picture I refer to the technique of “collecting questions”. By this I mean that we often socialise our design with the intent of getting questions answered. The other way to look at this is to as you socialise the architecture is to listen to the questions stakeholders ask and make note of these. These questions are what form your working out. If the asset manager asks if the technology fits the skill set of his team of .Net developers and you present a java solution he isn’t going to be happy.
The Architecture on a Page is the answer to the question but you need to show your working out and to make sure you have considered everything in your architecture. To do this make sure you go collecting questions.

Architecture Debt

14 December 2012

I have had the idea of Architecture Debt on my mind of late, most designs have something in there that you could class as Architecture Debt. Mmmmmmmm