When you want to enable MultiFactorAuthentication (MFA) for Azure / Intune / Office 365 / Dynamics 365 and you are using federated logins and want to have the MFA provider to be on-premises (integrated with ADFS/PingFed/other) integrated.. you might run into an issue where the Azure MFA page keeps popping-up and asking you to register […]
Category: Active Directory
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….
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 126.96.36.199); part two of the mS-DS-ConsistencyGuid as the immutable ID.
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.
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.
Microsoft released a new whitepaper this week that gives an insight in why you should protect your privileged accounts. One of the techniques described is the PassTheHash attack which is a sophisticated attack but fairly easy to execute. These attacks have been seen in the “field” and are being used today. If you work with […]
Did your AD jump back to the year 2000 during the past weekend? .. This could have happened if you are syncing your time with the USNO.NAVY.MIL, as they apparently had a disruption on the 19th. see http://tycho.usno.navy.mil/ntp.html But if time jumped back on your AD, you’re in trouble.. and the way to get […]
I was trying to get a test environment up and running that should reflect the production environment of my customer (off course at the customers site.. secured and all).. one task was to duplicate the OU structure, group structure and user information (without passwords). Browsing through the web I found a VBS script that can […]
In a previous entry I’ve explained how you can run services under the new Managed Service Account. Say now that we want to use this service account in combination with Kerberos and the account needs to be trusted for delegation. We set an SPN to it, but in the Active Directory Users and Computers, we seem to be unable to find the trusted for delegation option.. Let’s take a closer look at these accounts once they have been created, to do this we’ll be using ldp.exe