As you might have noticed, the last few posts are all about identity and the so called Secure Hybrid Access solutions. This one fall under that same category and is not sponsored by, but I did get a test account from them…. Active Directory or any identity store is usually used as the primary source […]
The Microsoft Surface Hub is a gigantic whiteboard on steroids. It allows you to .. (dhu) Whiteboard, but also allows you to join meetings through Skype or Teams, load PowerPoint/Word documents, connect you to your Office 365 services and much much more. Now the device in itself is special already, with many Mic’s and Camera’s […]
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
When you have ADFS hosted on Azure (as per my previous post), you might want to look at using Traffic Manager and then especially the probes and the endpoints..
Euhm.. oops.. this is embarrassing… we’ve found a bug. Well one of my readers did and I investigated further. When you follow the directions as below, you will notice the Traffic Manager will always set the endpoints as healthy. Despite whatever the status of the backend service is. So.. the bug in this case is that:
WAP will always listen for /adfs/probe despite the published rules. This is causing issues, cause as long as the WAP is up, that probe endpoint is up too. Your ADFS farm could be stone cold dead, according to WAP, all is fine. And as the traffic manager is relying on the /adfs/probe to determine the endpoint health, traffic manager will still happily send traffic to the endpoint as long as WAP (not ADFS) is up.
While this blog talks (and solves) the same problem: http://www.gi-architects.co.uk/2017/01/traffic-manager-endpoint-monitor-and-adfs-adfsprobe/ I think their workaround (although it actually works) is not the best. It involves installing IIS completely to then be able to rewrite the inbound URL to the correct one. There is a reason however why ADFS was removed from IIS (version 1.1 used to install IIS Web Services). It opens up too much.. and therefore I think its not that nice. So.. while I’m working on this.. head over to their page, use if required, until I have a better solution.
>>In short, this one goes back to the drawing board..<<<<
So, this post is to help you to configure ADFS behind the Azure Traffic Manager and ensure proper failover on service unavailability.
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….
Read more
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.
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.
[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.