In my previous post, I talked about the possibility of using Kerberos Constraint Delegation to avoid having passwords in AAD. However, sometime you want to have a few passwords in AAD-Domain Services to ensure that administrators can still login to the VM’s interactively (RDP) or users are able to use certain services that are not published with Kerberos or aren’t web services.
In this post we will look at editing the configuration of AAD-Connect to synchronize the passwords* of users that have an attribute in AD present so that some users (like administrators) will be able to login to VM’s joined to AAD-DS using their on-premises passwords.
* see note below
New (and only available within Azure) are the Azure Active Directory Domain Services. This service is based on Azure Active Directory and the data replicated into it. It provides Domain Services as a service to subscription administrators and can be very useful for many scenario’s where domain services are required, but security or management of domain controllers in the cloud is a concern.
In many documents, you will see that you need to replicate user password [hashes] into AAD to make it fully work.. but this post is about how you can avoid that using Kerberos Constraint Delegation with Protocol Transition….
Ever since playing with BGP I was looking for a way to make redundant tunnels. As the local internet provider here would only allow me a single IP address, I looked at the other side. What if we have two Azure regions that have a VPN tunnel to my SRX and between each other. Routing would be dealt with by BGP and thus, I should be able to connect to both VNET’s through each of the VPN tunnels.
Many companies struggle with concepts of “cloud networks” and how it relates to their on-premises networks. How do you deploy a firewall in there, with multiple subnets? Do we need multiple VNET’s and what about those subnets? Well, this post is about what you actually need to understand prior to deploying 3rd party firewalls (and/or VNets) and how routing works inside a VNET, and finally the common mistake of comparing an Azure VNET to a Hyper-V/VMWare VNET.
Hosting applications in Azure usually requires some form of connection to the on-premises networks. You could use Point-to-Site dialup or ExpressRoute, but Site-2-Site VPN’s seems the most use technology, and certainly is cheaper than ExpressRoute connection.
But what if you want to use multiple links for failover? What if your local firewall fails or the internet connection itself? Well, that’s why Azure supports MultiSite VPN’s. While it is capable of having two tunnels from on-premises to Azure with preferences, there is no automatic failover support. That means that if tunnel 1 goes down, tunnel 2 is NOT automatically activated. You need to disable tunnel 1 in Azure itself and only THEN tunnel 2 comes up. Which is annoying, but there is another way to fully automate this.. BGP, Border Gateway Protocol.
A lot of customers on Azure want to use the 3rd party firewalls that are available in the Azure Marketplace. But when it comes to Site2Site VPN connections, sometimes it doesn’t work as expected. Especially when using different vendors on-premises.. Why? let’s find out…
Congratulations!, you got your Enterprise Agreement enhanced with Azure!, now what’s next, you got activation emails and you want subscriptions, but who manages subscriptions? what if the company is rather complex and you don’t want the IT admin in charge of all subscriptions let alone view the company global spending on Azure services? In short, what about the Enterprise Governance on Azure in an EA enrollment?
Apart from each service on the cloud to follow a governance and security model, it is vital that the “cloud” entry points also follow a governance model as determined by the company. After all, while cloud can encompass many services, itself is a service too that generates invoices which need to be controlled to avoid abuse and to ensure oversight is added. In this chapter, we describe the Azure model with regards to governance..
The good thing about new software is that bugs and ‘features’ are removed.. the bad is that sometimes what ever you have blogged about makes either no sense, or even worse it only applies half to it from that point on.
So as AADSync was replaced by AD Connect, I got emails about the configuration of the mD-DS-ConsistencyGuid configuration in AD Connect not correctly working anymore. So, in order to relieve me from those email (you can still send them no worries) but more to make everyone aware of how this works in AD Connect (tested version 220.127.116.11); part two of the mS-DS-ConsistencyGuid as the immutable ID.
Azure Active Directory and thus any relying party on that service (such as Office 365) has two different modes for (your) custom domains that are added to it. Managed and Federated. Managed means that the authentication happens against the Azure Active Directory. The password (-hashes) of the user accounts are in Azure AD and no connection to any (on-premises) Active Directory Domain is made.
Managed domains have the advantage that you don’t require any additional infrastructure, and setting up the identities for logging on to Office 365 for example, is fairly easy. However, it does not support any Single-Sign-On which most companies do want. That is why AAD also supports Federated domains, in this case the authentication for a user happens against the corporate (on-premises) Active Directory through a service called ADFS (Active Directory Federation Services). More information on federated versus managed can be found on the Kloud blog (https://blog.kloud.com.au/2013/06/05/office-365-to-federate-or-not-to-federate-that-is-the-question/)
In this article we are going to take a look at how the federation service can be hosted in Azure (and possibly also on-premises) and what the architectures might look like.
Paul Williams talked in his blog about using another attribute from on-premises Ad’s to act as the ImmutableID for Azure Active Directory (http://blog.msresource.net/2014/03/10/windows-azure-active-directory-connector-part-3-immutable-id/)
While making a very detailed blog entry on why and which attribute to choose, there wasn’t a guide on how to make this work in AADSync.
So a recent project got me thinking about this. In this particular scenario there is already a forest (1 domain) using DirSync to replicate their users to AAD, and the requirement is to prepare for an AD migration, while also adding other users to the same AAD tenant. As usual, user objects might be duplicate between the two forests and we want to use the mS-DS-ConsistencyGuid attribute to be the immutableID.