markwilson.it

Tag: Microsoft Azure

  • Adding Microsoft Azure services to an existing Office 365 tenant

    If you have an Office 365 subscription, you use Microsoft Azure because Azure Active Directory is the underlying directory service – regardless of your chosen identity model (even if you use federated identity, you’ll sync your users to the cloud).

    Within the Office 365 admin center, is an Azure AD link although, if you click on it you may find you need to sign up for an Azure subscription. Don’t worry about this – it’s just provisioning access to the management portal – and once you have access, you’ll find your Azure Active Directory and can configure settings like logon page branding, self-service password reset, multi-factor authentication, etc.

    When I clicked though, I was confused to see that all I had was Active Directory and Settings – no virtual machines, SQL, networks, or anything other Azure services.

    Azure - AD created by Office 365

    So how do you go about adding Microsoft Azure services to an existing Office 365 tenant? I asked my colleague Tim Siddle (@brainchyldeuk) who told me the simplest way is to sign up for a free one-month Azure trial.

    Even if that’s not available (in my case Azure said I already have a subscription), it will let you either sign up for a different offer (on a pay-as-you-go basis) or view existing subscriptions.

    Azure - Free Trial is Not Available

    After running through the PAYG subscription sign-up process, where I verified my phone number, supplied credit card details and agreed to the terms and conditions, my Azure management portal was looking much more complete and, as can be seen from the screen shot below, I now have two distinct subscriptions on the same account – one for my Access to Azure Active Directory (part of my Office 365 subscription) and one for Pay-As-You-Go access to other Azure services.

    Azure - Management Portal showing multiple subscriptions

    Finally, if you’re worried about what all this might cost, there’s an Azure pricing calculator.

  • Troubleshooting missing objects in Azure AD sync

    I have a half-written blog post about Microsoft Azure Active Directory (AAD) Connect – the latest incarnation of the directory synchronisation engine used to populate a cloud directory for Office 365 and other online services. That post will stay half-written for a while longer as it needs a bit more work but, yesterday, I was working with a customer whose AAD sync was missing some users. I’d set it up a couple of months previously and it had been working well, but clearly something had gone awry.

    Microsoft knowledge base article 2643629 describes why one or more objects don’t sync when using the Azure Active Directory Sync tool but my problem turned out to be a lot more fundamental.

    I checked the Synchronisation Service Manager (miisclient.exe) and found that there hadn’t been a sync for over three weeks. Then I looked in the Task Scheduler on the AAD Sync server; the Scheduled Task was still there and it had last run a couple of hours previously. Digging a little deeper and looking at the history though, showed that the task had been failing for a few weeks (every 3 hours), because a previous task was still running.

    So, I restarted the server (to clear out long-running processes) and ran the sync, then watched in the Synchronisation Service Manager to check that it started logging the synchronisation events again. Once the sync was completed (with lots of changes, as expected), I changed the timeout on the scheduled task to 2 hours so it should always end before the next begins.

    A delta sync sorted most of the issues, but I did need to force a full sync to get all of the missing users up to the cloud, by running directorysyncclientcmd.exe initial.

    Incidentally, we’re all used to running idfix.exe before implementing directory synchronisation but occasionally admins create problem objects afterwards too… somehow an account had crept into scope that had a space in the username and no UPN. Predictably, AAD sync didn’t like that and my customer was being emailed after each sync with a notification that AAD Sync was:

    Unable to update this object in Azure Active Directory, because the attribute [Username], is not valid. Update the value in your local directory services.

    As Joran Markx explains, you can control who the identity synchronisation error reports are sent to by editing the technical contact for the tenant.

    Resources

  • Resource naming restrictions in Azure

    Whilst creating a virtual machine in Azure IaaS last week, I came across an interesting issue…

    I was creating a temporary server and didn’t fully understand the customer’s naming scheme, so I replaced the numerical part of the server name with xxxxxx. Then, when provisioning, I saw that deployment to the resource group had failed, with the following message:

    statusCode:BadRequest

    statusMessage:{“error”:{“code”:”DomainNameOperationFailed”,”message”:”Unable to create domain name ‘DIRSYNCxxxxxx’: ‘You used a word that may be considered offensive, or the word is embedded in another word.’.”}}

    xxxxxx (or probably xxx) appears to be on a Microsoft banned words list! When I changed xxxxxx to 000000 and repeated the operation, everything was fine, although I cant find a list anywhere of reserved words/resource naming restrictions in Azure (understandably, I guess).

  • Reconfiguring Azure AD Sync – rip and replace!

    I had an interesting learning experience recently, whilst working with a customer to implement some Microsoft Online services.

    They have an existing AAD Sync installation, although from time to time that stops working when Microsoft changes the IP addresses of the servers that are needed for synchronisation. This is not a recommended configuration – but the reasons why are well-described in David Ross’ post on using a proxy with Azure AD Sync Services. To limit the number of IP addresses in their firewall and router configurations, this customer places hosts file entries on the Azure AD Sync server, meaning that Azure AD Sync only uses two IP addresses to find the hosts:

    134.170.172.140        adminwebservice.microsoftonline.com
    191.235.135.139        login.microsoftonline.com

    Microsoft publishes a full list of Office 365 URLs and IP addresses, together with an RSS feed for changes.

    Anyway, to cut a long story short, my customer created a test environment by cloning existing servers into Azure IaaS. I ran IdFix against test directory objects, changed the UPN on the user accounts to match the domain we had associated with Office 365 (test.companyname.com) and ran the Microsoft Azure Active Directory Sync Services tool (directorysynctool.exe) to set Azure AD Sync up with the new, test Office 365 tenant. Then I sat back and waited for the changes to sync.

    To my horror, I found that the changes didn’t sync to the test Office 365 tenant, but to production! Running miisclient.exe confirmed that the original connectors were in place and had had not been changed by re-running the Directory Sync Services tool.

    Unfortunately, because the production AAD Sync server was unable to connect to Azure (due to IP address changes…), we couldn’t force a sync from that server to overwrite the stale directory information, which meant late night working was needed to get emergency changes in place and restore service.

    Once the production AAD Sync was up and running again, the live directory data was re-synced to Azure AD and services that relied on this (Intune-managed mobile devices were the obvious ones) started working again.

    As expected, the sync with the correct directory over-wrote the changes from the stale directory and the login names for those users that had changed to @tenantname.onmicrosoft.com (because their UPN from the test domain was not valid in the production tenant) reverted to the correct UPNs (which have verified domains in the tenant).

    In the cold light of day, I realised that the issue was not caused by me – the only reason synchronisation from the test environment hadn’t over-written the live directory sooner was that the test AAD sync server didn’t have Internet access and then I’d disabled the scheduled task whilst running the Directory Sync Services tool. Once it was enabled it simply did its job – but the key learning point for me is that reconfiguring Azure AD Sync is not as simple as re-running the Directory Sync Services tool and supplying the necessary details – it really needs to be ripped out and run from scratch because directly editing the connectors is unsupported:

    Microsoft does not support modification or operation of the Directory Sync tool outside of those actions formally documented.  […]  Unsupported actions include:

    • Opening the underlying FIM Sync Engine to modify Connector configuration
    • Manually controlling the frequency and/or ordering of Synchronization Run Profiles or changing the attributes that are synchronized to the cloud.

    Any of these actions may result in an inconsistent or unsupported state of the Directory Sync tool and as a result, Microsoft cannot provide technical support for such deployments / usage of the tool. Filtering configurations applied to your directory synchronization instance aren’t saved when you install or upgrade to a newer version. If you are upgrading to a newer version of directory synchronization, you must re-apply filtering configurations after you upgrade, but before you run the first synchronization cycle.

  • Short takes: PowerShell to examine Azure AD tenants; check which Office 365 datacentre you’re using

    More snippets from my ever-growing browser full of tabs…

    PowerShell to get your Azure Active Directory tenant ID

    Whilst researching Office 365 tenant names and their significance, I stumbled across some potentially useful PowerShell to read your Azure Active Directory tenant ID.

    Get-AzureAccount

    I’m not sure how to map that tenant ID (or even the subscription ID, which doesn’t seem to relate to any of my Office 365 subscriptions) to something meaningful… but it might be useful one day…

    Script to retrieve basic Office 365 tenant details

    I also found a script on the Microsoft TechNet Gallery to retrieve basic details for an Office 365 tenant (using Get-MsolDomain, Get-MSolAccountSku and Get-MSRole).

    Check which datacentre you’re connected to in Exchange Online

    Office 365 uses some smart DNS tricks to point you at the nearest Microsoft datacentre and then route requests across the Microsoft network. If you want to try this out and see where your requests are heading, just ping outlook.office365.com and see the name of the host that replies:

  • Self service password reset is not available for users on a trial Office 365 tenant

    One of my customers is currently running an Office 365 pilot using a trial E3 tenant.  When Microsoft announced that self-service password reset is to be made available to cloud-based Office 365 users without the need for a separate Azure AD basic or premium subscription it sounded great to us as the requirement for users to reset their own passwords was one of the challenges we faced.  Unfortunately it’s not quite so simple – or at least not if you are not using a paid product (for example if you’re on an Office 365 trial).

    Just to be clear, self-service password reset is still available for Global Administrators in Office 365 – it has been as long as I’ve been working with the product – I’m talking here about “normal” users.  In the Office 365 Admin Center, listed under Service Settings, Passwords is a section titled “let your people reset their own passwords” – but the feature is not actually controlled from within the Office 365 Admin Center – it redirects to the Azure AD Admin Center:

    In my own tenant, that led to a simple sign-up for a $0 Azure subscription following which I can see my directory (remember Office 365 uses Azure AD for authentication), complete with all the domains and settings I configured via the Office 365 Admin Center over the years.  Dig a little deeper and in the configure screen is the ability to customise branding and to set the user password reset policy:

    After enabling self-service password reset there are more options to control the experience (for example the available authentication methods) and a link to allow users to set up their details.  Unfortunately, none of this is available with a trial tenant and, when I tried to configure it, setting up an Azure subscription failed at the mobile verification stage and a service request raised with Microsoft Office 365 support confirmed that this is by design.

  • The relationship between Microsoft Office 365 and Azure

    At a recent partner event, Microsoft Partner Technical Specialist, Robert-Jan Gerrits, answered a question that many people ask: does Office 365 run on Azure?

    The short answer is “no” – the Office 365 infrastructure is dedicated – i.e. it’s not a bunch of VMs running on Azure; however there is a slightly longer answer.

    Office 365 uses Azure for:

    • Office 365 video (media)
    • Azure blob storage (storage)
    • Azure AD for identity (identity)
    • Power BI app (cloud services)
    • Access services (storage)

    Over time, we can expect to see more and more Office 365 components using Azure services but, for now, Office 365 is (almost) a standalone environment.

  • “Microsoft accounts” vs. Microsoft’s “organizational accounts”

    If you’re using Microsoft’s online services, you might reasonably expect to authenticate against some form of directory service.  And, if you have your own directory service (like Active Directory), you might reasonably expect to be able to synchronise it with your cloud identity to provide a holistic view to end users. Unfortunately, whilst both of these things are possible, the end result can be really confusing and I’ve just had to explain it for one of my customers.

    You see, a “Microsoft account” is not what you use to log on to Office 365 (or Intune, Azure, etc.) – for that you need an “Organizational account” (which is held in Microsoft Azure Active Directory) – although you might have logged on to your Windows PC, phone or tablet with a Microsoft account.

    Still with me? No! Well, let me quote from an MSDN article:

    “Q. What is the difference between “Organizational account” and “Microsoft account”?
    Organizational account     is an account created by an organization’s administrator to enable a member of the organization access to all Microsoft cloud services such as Microsoft Azure, Windows Intune or Office 365. An Organizational account can take the form of a user’s organizational email address, such as username@orgname.com, when an organization federates or synchronizes its Active Directory accounts with Azure Active Directory. […]

    Microsoft account, created by user for personal use, is the new name for what used to be called “Windows Live ID”. The Microsoft account is the combination of an email address and a password that a user uses to sign in to all consumer-oriented Microsoft products and cloud services such as Outlook (Hotmail), Messenger, OneDrive, MSN, Windows Phone or Xbox LIVE. If a user uses an email address and password to sign in to these or other services, then the user already has a Microsoft account—but the user can also sign up for a new one at any time.”

    Right. Hopefully that’s a bit clearer? Unfortunately the whole thing gets really messy when you have multiple browser tabs connected to different services and I often find I have different browsers (or InPrivate/Incognito browser sessions) running in parallel to access services.  One approach, although probably not recommended, is to manually synchronise the passwords between a Microsoft account and an Organizational account that have the same email address to give the illusion of single sign-on.

    Maybe one day all of the consumer services will move to Azure Active Directory and we can just have a single identity. Probably not though… that’s what Microsoft Passport (Windows Live ID’s predecessor) was trying to do back in 2001 and it felt a bit “big brother” to some people (although today we seem quite happy to have Google and Facebook act as identity providers for multiple services).

    Post Script

    Since I wrote this post, “organizational accounts” have become known as “work or school accounts”, which I guess makes things a little clearer, even if the phase is a touch unwieldy!

  • Microsoft #TechDays Online 2015

    Last week, was Microsoft UK’s TechDays Online conference, held over three days with thousands of virtual attendees watching/listening to sessions on a variety of topics, starting off in the IT Pro arena with a keynote on Windows 10 from Journalist and Author Mary Jo Foley (@MaryJoFoley), Windows Server, on to Intune, Office 365, progressing to a variety of Azure topics, containerisation and DevOps with a keynote from Microsoft Distinguished Engineer Jeffrey Snover (@JSnover) and eventually into full developer mode with a keynote from Scott Hanselman (@SHanselman).

    This is the fourth year that Microsoft has run these events and I was fortunate to be invited to watch the sessions being recorded.  I attended the first afternoon/evening and the second day – driving my Twitter followers mad with a Microsoft overload. For those who missed it, here’s a recap (unfortunately I couldn’t commit the time to cover the developer day):

    (I later retweeted this:)

    And we continue…

    Actually, he didn’t – I later published this correction:

    And back to my stream of Twitter consciousness:

    Sadly, I missed Mary Jo Foley’s keynote (although I did manage to get over to Microsoft’s London offices on the second evening for a Live recording of the Windows Weekly podcast and caught up with Mary Jo after the event).

    Sessions were recorded and I’ll update this post with video links when I have them.

  • Choosing an Office 365 identity model (when to use ADFS)

    At the time of writing, Microsoft Office 365 has the ability to work with three identity models:

    • Cloud identity (stored in Microsoft Azure Active Directory).
    • Synchronised identity (a copy of the objects from an on-premises Active Directory is made in Microsoft Azure AD), optionally with synchronised password hashes.  This is also known as same sign on (not single sign on as there are still two separate objects, albeit two objects that are kept synchronised).
    • Federated identity, using a federation service (such as Active Directory Federation Services, but others are supported) to authenticate users in an on-premises directory following which authorisation can be granted to Office 365 resources. This is also known as single sign on.  In this instance, directory synchronisation is still used to populate the Azure AD with user objects, although authentication happens on-premises.

    Whilst the majority of small businesses will be fine with cloud identities, many of my conversations with enterprise customers start off in the directory synchronisation space. Generally, synchronisation is performed using the Office 365 DirSync appliance (a customised version of Forefront Identity Manager) although, more recently a new tool (Azure AD Sync) has been released that will eventually replace DirSync.  At the time of writing the main difference is that Azure AD Sync supports multiple forests (DirSync is a single forest solution) but it doesn’t support password synchronisation (still a major advantage for DirSync).

    In general, the approach I recommend is to choose the simplest model for the organisation’s needs. The cloud identity model can work well when there is no on-premises directory service or there is no requirement to integrate; synchronised identity is the most commonly used (assuming there is an existing Active Directory) but sometimes federation is required:

    1. If there is an existing ADFS infrastructure.
    2. If a third party federated ID provider is in use.
    3. If Forefront Identity Manager 2010 is in use (which does not support password synchronisation).
    4. If there are multiple on-premises Active Directory forests (although Azure AD sync may negate this requirement).
    5. If smart cards or other third-party multi-factor authentication solutions are in use (Azure AD does have an MFA capability, although there are some restrictions on its use).
    6. If custom hybrid apps or hybrid search are in use (SharePoint).
    7. If a hybrid Lync solution is in use (i.e. placing users with enterprise voice capabilities on premises and those that don’t need voice in Lync Online, sharing the same SIP namespace).
    8. For self-service password reset via a web service (only administrators have self-service password reset in Office 365).
    9. If there is a requirement to audit logins and/or immediately disable accounts.
    10. If there is a requirement for single sign-on (i.e. accessing Office 365 workloads with the same user credentials as on-premises).
    11. If there is a requirement to restrict client logins by time or location.
    12. If the organisational security policy prevents the synchronisation of password hashes to Azure AD.

    On a related topic, the Microsoft Online Services Sign-in Assistant (MOSA) for IT Professionals only exists to simplify the user experience (handling tokens, etc.) and is generally not required with modern versions of Office. Administrators using PowerShell may still need it though.

    Finally, if ADFS is down, there is no way for users to authenticate. For that reason, federated infrastructure needs to be highly available (e.g. multiple ADFS proxies and multiple ADFS servers).  One method that’s starting to be commonly recommended is an “ADFS safety net”, using DirSync as a fall back (it’s possible to move between identity models on demand) but obviously that’s only an option if your organisation’s security policy allows the synchronisation of identities (including password hashes to minimise the impact on end users).

    For reference, the PowerShell commands are:

    Convert-Msol-DomainToStandard -DomainName domainname.tld -SkipUserConversion $true
    Convert-Msol-DomainToFederated -DomainName domainname.tld

    Set-Msol-DomainAuthentication -Authentication Managed -DomainName domainname.tld
    Convert-Msol-DomainToFederated -DomainName domainname.tld

    Credit is due to Michel de Rooij (@mderooij) for the ADFS safety net tip.