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..
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.
These are my notes on the newer Checkpoint VPN stuff.. but still working on actually testing them.. – I put a 2016 date on it to remove it from the main page.. Seems the MSS clamping on Azure VPN’s needs to be 1350, my PPPOE adapter needed to be 1492 for du Connections. Note: MTU […]
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.
[update 21-Aug-2017: The latest version of Azure AD Connect have the functionality built-in to select the ImmutableID. There is no need to hack the rules manually anymore.. read more about it at: http://blog.azureinfra.com/2017/08/21/immutableid-ms-ds-consistencyguid-adconnect-final-part/]
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.
When you create a new forest or new domain, you use the Domain Admin credentials. Through the use of the “Administrator” account you can control each and every workstation and server. You can install Exchange, System Center products and much much more. But Microsoft is probably thinking twice now about the framework they have chosen wherein the Administrator is master of your infrastructure.
As the Administrator account is so powerful, it’s a sweet spot for hackers, the target to get. And that’s probably why many people rename the administrator account to Guest (and vice versa) or something else. Many others keep the Administrator name but change the password to a very long one including special characters, but even that seems futile, by the discovery of an advanced hacking technique called Pass The Hash.
In a previous post we looked at the ability of creating a Site-2-Site connection from Checkpoint to Azure using a Dynamic Gateway. In this post, we look at client-dialup (VPN) into the Azure network and establish routing between all the sites involved.
I’ve been trying to get RDS Gateway to work behind my WAP proxy server which is included in Windows Server 2012 R2 and v.Next version. While it is possible to implement ADFS based authentication based on the URL: http://technet.microsoft.com/en-us/library/dn765486.aspx
But what if we wanted to publish the simple RDS Gateway on our backend server for direct RDP access.. ?