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.. ?
In this post, how to configure a Site2Site VPN connecting using a Checkpoint firewall.
[EDIT: The instructions below are for R77, which is a really old version. I’m currently writing the instructions for the R80.20 version, but it seems it’s a bit harder to get the S2S tunnel up and stable.. certainly on my PPPOE internet connection… more updates soon!
But in case you still want to make this work, please check this hidden article with my notes.. that have not been validated yet! [/EDIT]
While http://msdn.microsoft.com/en-us/library/azure/dn133795.aspx tells you how to create the Site2Site VPN, the firewall part only covers Juniper or Cisco appliances. As I do not own such a device, I got to work on the Checkpoint together with Syed Pasha.
Below the network overview…
Geo Clustering exists in many options, and dependent highly on the requirements and technical capability. This post is to discuss some options and things to consider before deploying any geo-cluster.
Data GEO- Redundancy
The first dependency in clustering is storage capability. Data from the workload in the cluster will be written to disk and that data needs to be available on both sites. Within Microsoft SQL AlwaysOn can replicate the data for the instances and ensure it is available on both sites. It is also possible to have the storage perform data mirroring.
When sending data from site A to site B, two options exist: Synchronous and A-Synchronous.
Synchronous: Data is written to BOTH sites before the application or server receives a successful write notification
A-Synchonous: Data is written to the primary site, the application or server receives the write, and THEN the data is written to the second site.
Within a synchronous architecture, there is very limited chance of data-loss upon a failure, as the application knows the data is written in two locations. With A-synchronous data loss can occur.
While synchronous looks most tempting, it requires fast connections between the storage / servers in order to reduce latency for every I/O write action. Therefore this is not always possible and a-synchronous is the only option left.
Storage mirroring or AlwaysOn data replication must be used to provide data geo-redundancy
So all documentation on BHOLD informs you there are “out of the box” reports available.. none of the articles show which reports they are.. so here they are..
So there are numerous scripts out there for setting the UPN of a user to match the Windows Email Address.. you can even do that in a single command (Powershell).. but would it not be better to actually read the primary e-mail address from the ProxyAddresses? .. so the following script will help you with that: Read more