Designing Azure AD standalone

Designing Azure AD

Designing Azure AD can be complex if we’re leaving local AD. We need to make sure we have naming conventions in order. What about our devices like printers, where will they go? Here we will go through the designing phase of our series.

Designing Azure AD

From Part 1: Our companies are going to use the same tenant, and they all have their own IT environments. In other words, they all have their separate IT environments.

As of now,  Azure AD has a flat OU structure. This gives rise to support and naming conflicts. Which is also the reason Azure AD Connect is so picky when it comes to conflicts…it just can’t handle them when exporting to Azure AD. In our scenario we need to be aware of this problem when designing Azure AD. We need naming conventions that work for all our companies.

We need to develop a naming convention for all companies being migrated into this one tenant.

  • Usernames
  • Office 365, Distribution and Security Groups
Usernames

Some companies like to use domain\e251301 – Which doesn’t make much sense to the user, but some legacy system requires it to work at all.

With Azure AD we won’t have that problem, and Microsoft encourages you to use UPN = Mail = SIP.

We will also use this for our migration. Every user should be changed to: First.Last@contoso.com

What attributes should we add? In this scenario, the more the merrier. We need to have a fleshed out Azure AD so that we can easily see which Country/Company/Department/Etc the user is located at.

First the basics, what is the bare minimum that Office 365 can use to create users?

      Attribute Explanation
          DisplayName
        User Display Name
          UserPrincipalName
        Login name

      That’s it. That’s all you need to create a user.

      Let’s add more information though:

      Attribute Explanation
      FirstName User First Name
      LastName User Last Name
      Office Self-Explanatory
      StreetAddress Self-Explanatory
      City Self-Explanatory
      State Self-Explanatory
      PostalCode Self-Explanatory
      Country Self-Explanatory
      Department Self-Explanatory
      PhoneNumber Self-Explanatory
      MobilePhone Self-Explanatory
      UsageLocation Office365 needsto know this. So that it can assign the closest datacenter to you. Uses CountryCodes E.g: US.
      LicenseAssignment Assign a license on the user – Use Get-MsolAccountSKU to get all licenses
      ProxyAddresses Set by Exchange Online (Same as UserPrincipalName)

      Groups

      We are dealing with several companies located in several countries.

      Having the “Keep it simple”-mantra in mind, I’m recommending a simple Country.Company.Usebase

      For instance, all users in a company based in France (Contoso France) will be: FR.CON.All

      Management-group for a company based in Norway (Adatum Norway) would then be: NO.ADA.Management

      Having a good naming system will also ease the work of the sysadmins. They can just search on Country.Company and they will find all relevant, and can create a new group if desired. This is what designing Azure AD is all about.

      The same applies to Distribution groups.

      We need to keep it as simple as possible and as functional as possible.

       

    Leave a Reply

    Be the First to Comment!

    Notify of
    avatar

    wpDiscuz