Identity

Confused by what the new Azure Lighthouse service is, and what it’s used for? All will be explained, succinctly and to the point.

If your application is running on a Kubernetes cluster in Azure (AKS, ACS or ACS Engine), then it is likely that you will need to access other Azure resources from your pods that are secured with Azure AD. These operations could include retrieving secrets from Key Vault, files from Blob storage or just interacting with other applications or API’s that use Azure AD as their identity provider. To be able to do this your application needs to be able to provide an identity to access these resources securely.

In an on premises world, with Active Directory, password expiry is easy. Set the required policy for your domain, make sure it’s applied and forget about it, AD will take care of enforcing password changes and compliance with your password rules. Moving your identity to Azure complicates things, and that’s what we are going to talk about today, and in particular password expiry and related processes in the world of Azure AD Connect.

Back in November I published an article on Azure Active Directory Domain Services (AAD DS), detailing some of the limitations of the service and what it is and isn’t intended for. If you’ve not read that I recommend going back and reading through that first so this article makes sense. Since this article was published there have been some big updates to the service that mean some of these limitations have gone away, so I thought it was time to detail some of these changes and what they mean for Azures Domain Controller as a Service offering.

I’ve seen a few forum questions lately from AWS users who want to (or have to) use Azure and whilst there are a lot of similar services in either platform, the new user experience and terminology can be very confusing if your used to AWS. This article is the first in a series of posts that I’m hoping will help users coming from AWS get to grips with Azure. To be very clear, I’m not looking to argue about which platform is best or why you should use one or ther other, I’m simply providing the information an AWS user needs to quickly get a grasp of Azure and relate it to what they already know.

The AAD DS team has released new features that mean some of the limitations in this article are no longer present. Be sure to read my update on this service to get the latest information. Azure AD has always been a little bit confusing to new users of Azure, the name implies it’s a cloud version of AD, but it quickly becomes clear to most that it very much is not.

Earlier last week I had a need to delete an Azure AD tenant, and this turned out to be a much more difficult task than I had originally anticipated so I thought I would document the steps I went through in case others encounter the same problems. 1. Disable AD Sync If your syncing your on-prem AD up to Azure AD you need to disable this from inside the Azure Portal so that it disconnects your users from the sync, otherwise you cannot delete your synced users.