Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2023-05-26) Presenting At Info Security 2023

Posted by Jorge on 2023-05-27


Oops, I’m doing it again…

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Advertisement

Posted in Active Directory Domain Services (ADDS), Backup And Restore, Conferences, Forest Recovery, Ransomware | Tagged: , , | Leave a Comment »

(2023-05-19) Hybrid Identity Protection (HIP) 2023 Global Conference Coming In August

Posted by Jorge on 2023-05-19


The Hybrid Identity Protection 2023 Global Conference is coming up in New York on August 23rd and 24th this year. Real people, real talks, real experience. Interested? Great, make sure to register quickly through the following link: https://www.accelevents.com/e/hip-global-2023. Oh, by the way, it is free!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Conferences | Tagged: , | Leave a Comment »

(2023-05-18) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (2)

Posted by Jorge on 2023-05-18


In the following article, I explained a scenario with test environments, where the SYSVOL replication breaks due to the use of snapshots. I also explained how to fix it.

Now, if you are using snapshots frequently to revert the test environment back to a certain state, fixing the SYSVOL will be part of that whole process. In addition, if you forget to fix the SYSVOL, you are working with a broken SYSVOL while not even realizing it, and that might have an impact one way or another.

Another approach to this problem is to disable the Generation ID process that detects any difference in the Generation ID between the VM and the registration on the computer account. That process is managed by the “Microsoft Hyper-V Generation Counter” (GenCounter) service. That service is not visible in the services.msc, but it is visible through Get-Service CMDlet. The idea is to disable that service on ALL DCs in the AD forest. The best way to achieve that is to configure a GPO in every AD domain, existing or new, that is linked to the “Domain Controllers” OU. That configuration in the GPO, tells every DC (RWDC and RODC) to DISABLE the “Microsoft Hyper-V Generation Counter” (GenCounter) service, but it will not stop it. A reboot of every DC, make sure that service is not started as it has been configured to be disabled. It is therefore a 2 step approach.

However, to configure a service in the System Services section of a GPO, the service itself must exist on the DC. Because the service does exist but is not visible, you can still not configure it through the GPMC. Another way to configure this is to use a registry preference. The downside of configuring this through a registry preference is that it tattoos the registry, meaning it will not be undone when you remove the configuration. When using a service in the System Services, it does not tattoo the system, and because of that it is preferred. Although not visible when you want to configure it, it is visible in the GUI if you want to remove it.

The easiest way to configure this as a service in the System Services section of a GPO, is to use PowerShell. And to help you out I have written some PowerShell code. That code can be found through the following link: Configuring New Or Existing GPO With The GenCounter System Service To NOT Start (i.e., Disable Generation ID)

PS: please make sure to test this first in a test environment. DO NOT use it in any production environment!

That code would need to be used per AD domain and should be executed locally on 1 RWDC per AD domain. Remember, it should be used within all AD domains in the AD forest! Before using the code, configure first the name of either an existing GPO or a new GPO. In case of a new GPO, the code will create that GPO. With either an existing or new GPO, for it configuration to be affective, it must be linked to the Domain Controllers OU.

Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!
Again: DO NOT DISABLE THE GENERATION ID PROCESS IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!

Please be aware, that when the Generation ID process is reenabled, after it has been disabled, it will detect a change which will trigger the behavior explained in the first part of the blog post. The fix of that is explained also in that first part.

Now, with a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:

  • Create and configure DCs and AD as needed
  • Shutdown ALL DCs in the AD Forest
  • For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
  • Boot up ALL or SOME of the DCs in the AD forest
  • Do whatever you need to do
  • When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot. ==> Because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.

Do you need to perform updates on the DCs or AD, then follow the next steps:

  • Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other ==> because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.
  • Boot up ALL DCs in the AD forest
  • Perform all required updates on either/both the DCs and/or AD
  • Shutdown ALL DCs in the AD Forest
  • For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
  • Delete the previous/older VM snapshot

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Backup And Restore, SYSVOL | Tagged: , , , | Leave a Comment »

(2023-05-13) Presenting At Experts Live 2023

Posted by Jorge on 2023-05-13


Need I say more?

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Backup And Restore, Conferences, Forest Recovery | Tagged: , , | Leave a Comment »

(2023-05-06) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (1)

Posted by Jorge on 2023-05-06


With many test environments, it is a common thing to create and configure a test environment with at least 1 AD domain and probably multiple domain controllers (DCs).

Before explaining what can happen and what all this is about, let’s just go back in time a bit to understand, why things work like they work.

Background

Apparently, one of the common things that occurred in production environments is that some admins created one or more snapshot of one or more virtual DCs before implementing changes, installing hotfixes/updates, and some even used it as a way to recover AD when needed. Another similar action on DCs running on physical hardware is restoring an image that contains the earlier state of the DC. The common cocktail of trouble, that resulted from any of these scenarios after reverting to a previous snapshot, is called USN rollbacks. With USN rollback, all other DCs have a higher USN for the DC that was reverted back through a snapshot. Put differently, the higher USN on the other DCs for the DC that was reverted back through a snapshot means those DCs all think that DC is already up-to-date, but in reality it is not. Updates from other DCs will therefore not replicate to that DC. This means inconsistencies, which in turn means different behavior. Examples of possible different behavior:

  1. different results in LDAP queries
  2. difference in authentication and authorizations
  3. ..and more.

The one and only solution of resolving the issues on a DC with USN rollback? Force demote the DC and clean up its metadata. After that repromote to a new DC.

More information about USN rollback can be found through the following links:

The Solution

The quick and easy solution? Stop using snapshots with DCs!

The Microsoft solution? With Windows Server 2012, Microsoft introduced “Virtualization Safeguards For DCs” in both Windows and its hypervisor “Hyper-V”. Other virtualization platforms, like e.g. and amongst others VMWare, also implemented the same mechanism in their hypervisor to offer the same “Virtualization Safeguards For DCs”. The core solution is the support for VM-GenerationID by checking for it and comparing it. The process is explained in figure 1, and examples of events, when a DC is reverted to a certain snapshot state, are displayed in other figures.

Figure 1: The VM-GenerationID Check And Comparison Process

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controller-architecture#safe-restore-detailed-processing

Figure 2: The Detection Of Generation ID And Its Current Value For The VM

Figure 3: The Detection Of Generation ID And Its Current Value For The Computer Account In AD

Figure 4: The Detection Of The Difference Between The Generation ID For The VM And The Generation ID For The Computer Account In AD

A Generation ID change has been detected.

Generation ID cached in DS (old value):
4655303322081246329
Generation ID currently in VM (new value):
9133133598227488399

The Generation ID change occurs after the application of a virtual machine snapshot, after a virtual machine import operation or after a live migration operation. Active Directory Domain Services will create a new invocation ID to recover the domain controller. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services aware backup application.

Figure 5: The Change Of The Invocation ID

The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is as follows:

InvocationID attribute (old value):
fd229607-190b-497d-b4a6-db886c407da3
InvocationID attribute (new value):
5b026ded-8c93-4645-a382-548f125d85ae
Update sequence number:
958540

The invocationID is changed when a directory server is restored from backup media, is configured to host a writeable application directory partition, has been resumed after a virtual machine snapshot has been applied, after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services-aware backup application.

Figure 6: Configuring The Generation ID Value Of The Computer In AD With The Generation ID Value Of The VM Itself

Figure 7: The SYSVOL Being Initialized As Non-Authoritative

When there is a difference detected in VM-GenerationID between what the hypervisor knows and what the DC itself knows, it will trigger the “Virtualization Safeguards For DCs” to protect the AD environment from USN rollback. The following actions occur:

  1. The identity of the database instance, a.k.a. the invocationID, is changed (Figure 5)
  2. The RID pools the DC knows about are invalidated
  3. A new RID pool is requested from the DC with the RID Master
  4. The SYSVOL is put in non-authoritative mode by deleting either the NTFRS or DFS-R databases, while at the same time keeping the existing content of the SYSVOL that is used to pre-seed it. (Figure 7)
  5. Any more recent changes or new objects in AD on other DCs that do not yet exist, are inbound replicated
  6. Any more recent changes or new files in the SYSVOL on other DCs that do not exist yet, are inbound replicated. This, however, does require those other DCs to be either in normal mode, or authoritative mode.

Now after reading this, you might think: “Oh, that’s cool! I can now use snapshots to restore DCs without messing up the DCs or AD”. Well, actually, no! DO NOT DO IT!

The Impact Of The Solution

The “Virtualization Safeguards For DCs” are intended for production DCs. However, DCs are also used in test environments. For the larger TEST environments, the same rules apply as in production environments, as most likely those TEST environments are used by multiple teams, multiple applications and are continuously up and running.

However, if you have a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:

  • Create and configure DCs and AD as needed
  • Shutdown ALL DCs in the AD Forest
  • For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
  • Boot up ALL or SOME of the DCs in the AD forest
  • Do whatever you need to do
  • When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot.

Do you need to perform updates on the DCs or AD, then follow the next steps:

  • Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other
  • Boot up ALL DCs in the AD forest
  • Perform all required updates on either/both the DCs and/or AD
  • Shutdown ALL DCs in the AD Forest
  • For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
  • Delete the previous/older VM snapshot

Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!

Now this looks easy, right? Are there any caveats to using these steps? Yes, there are! Have a look at the Virtualization SafeGuard for DCs in step 4 (the one about the SYSVOL).

Think about it, when reverting all DCs in an AD domain, all those DCs in the AD domain, are in a non-authoritative state and waiting to perform (initial) replication from a DC with either a normal or authoritative SYSVOL. Because all DCs in the AD domain are in a non-authoritative state, there is NO DC with either a normal or authoritative SYSVOL. Oops! The consequences are that all DCs are waiting for each in terms of SYSVOL replication. You might not even notice it immediately, but later on, you might experience weird behavior, like no SYSVOL replication, inconsistent SYSVOL content, inconsistent GPO behavior, etc

The Fix

Either immediately after reverting the snapshot, or later on if still possible, you need to repair the SYSVOL within an AD domain by marking 1 RWDC authoritative for the SYSVOL, and all others, incl RODCs, non-authoritative for the SYSVOL. The RWDC authoritative for the SYSVOL will initialize and mark itself as the primary member of the special and default DFS-R Replication Group called “Domain System Volume” with a DFS-R Replicated Folder called “SYSVOL Share”, while all other RWDCs/RODCs in that same AD domain, will also reinitialize and wait to perform initial replication from an RWDC with either a normal or authoritative SYSVOL.

The steps for this are described in the following blog post: (2011-06-22) Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 4)

When having multiple DCs in an AD domain, and even multiple AD domains with multiple DCs within the AD forest, that can be quite exhaustive to execute manually. Because of that, I have written some PowerShell code to do this automatically per AD Domain. The code can be executed on any DC, and by default, it will mark the RWDC with the PDC FSMO role as the RWDC with the authoritative SYSVOL, while marking all others as non-authoritative. If you need to have another RWDC to be authoritative, then specify its FQDN in the variable.

The code can be found through the following link: Fixing Broken DFS-R Replication Group (SYSVOL) Replication Between All Replication Group Members While Assigning A Primary Member As Source

PS: please make sure to test this first in a test environment. DO NOT use in any production environment!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Backup And Restore, SYSVOL | Tagged: , , , | Leave a Comment »

(2022-12-19) Ransomware And The Impact On Your Hybrid Identity Environment

Posted by Jorge on 2022-12-20


For many years, organizations have been using Active Directory (AD) as their central on-premises identity directory service. Throughout those years many system and/or identity related configurations have been made to support different requirements. About just more than a decade ago Azure Active Directory (AAD) was officially released. For those organizations adopting AAD, something was needed to enable the so called hybrid identity environment consisting of AD on-premises and AAD in the cloud, in terms of authentication and identity provisioning and deprovisioning.

To support identity provisioning and deprovisioning in AAD using AD as the authoritative source, Microsoft offered the Windows Azure Active Directory connector for Forefront Identity Manager (FIM) and Microsoft Identity Manager (MIM). In addition DirSync was also offered, which was later replaced by Azure AD Sync, which was also replaced by Azure AD Connect (AADC). Today AADC is the tool to provision, and deprovision, users, groups and computers sourced from AD in AAD.

Not taking into account the order of offering, today to authenticate against AAD when having an hybrid identity environment, the following options exist, and can therefore be used:

  1. Federated SSO
  2. Pass-Through Authentication (PTA), with or without Seamless Sign-On
  3. Password Hash Synchronization (PHS), with or without Seamless Sign-On

Now, the way to configure any of the available authentication mechanism, is through AADC wizard. The first option “Federated SSO” can be configured by yourself if you know what to do (which is not really difficult), or you can use the AADC wizard. For the last 2 options you must use the AADC wizard. The choice of an authentication method is done during the initial installation/configuration of AADC. Afterwards it is also possible to change the authentication method, and that can be done through the AADC wizard and changing the user sign-in.

Figure 1: Configuring The Authentication Mechanism, A.k.a. The User Sign-In, Through The AAD Connect Wizard For Azure AD

[AD.1] Federated SSO

When choosing Federated SSO, currently the AADC Wizard supports the configuration option to federate with either ADFS (Federation with ADFS), or Ping Federate (Federation with PingFederate). In both cases, you can also choose “Do not configure”, but then you have to configure all by yourself in the corresponding federation system. If you know what is needed and what to do, you can do this yourself, as it is really not that difficult. The latter option “Do not configure” is for sure required when you need some serious customization in the configuration of the federation systems and the processing of the rules for the relying party, a.k.a. application.

This option is most of the time chosen when an organization already has a federation system in place. When this option is chosen, the custom domain in Azure AD is configured as a federated domain. This means that when Azure AD wants to authenticate a user, that is part of a certain custom DNS domain, it will determine the domain is federated. Due to that, it will redirect authentication to the corresponding federation system. The federation system in turn authenticates the user against the directory service the user belongs to, and the user is redirected back to Azure AD.

So, in this case, Azure AD depends on the federation system and the federation system (e.g., ADFS) depends on the directory service (e.g., AD). In the case of a ransomware attack against either or both the directory service (e.g., AD) and/or the federation system (e.g., ADFS), authentication against Azure AD for federated domains DOES NOT work anymore.

What can you do about this? Well, the initial thought could be to “fix” the directory service (e.g., AD) and/or the federation system (e.g., ADFS). Unfortunately that can take some serious time, especially if it is too complex or worse if no backups are available. The best way to have a backup authentication, when using federated SSO, is to in addition enable Password Hash Sync (PHS) through AADC. More details about PHS later. As mentioned earlier, when using federated SSO, the custom DNS domain in Azure AD is configured as a federated domain and because of that, Azure AD will always redirect authentication to the federation system. To enable Azure AD to take over authentication, the federated domain needs to be converted to a managed domain. Because Azure AD, through PHS, has the on-premises password hashes, and the domain has been converted, Azure AD will be able to authenticate users, while AD and/or e.g. ADFS are not available yet. Make you test this conversion and determine the impact!!! I have seen it happen where Identity Protection kicks in after converting the domain and the user authenticates natively against Azure AD. When all is good and up and running again, you can convert the custom DNS domain back from managed to a federated domain so that AD/ADFS take over authentication again. Please do take into account the possible impact of people changing their password against Azure AD after converting from federated to a managed domain, and before converting back. When converting back, if a password change occurred, the password known by Azure AD does not match the password known by AD. If you have recovered your AD from a backup, and therefore went back in time, that is also a separate challenge on its own!

MY RECOMMENDATION: do you have and use federated SSO, and you do not have PHS enabled? Enable PHS as soon as possible for ALL synched accounts!!! Also make sure to have a tested and automated plan ready to convert the federated domains in Azure AD to managed domains, so that Azure AD can take over authentication. This will save your and your organizations bacon with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.2] Pass-Through Authentication (PTA), with or without Seamless Single Sign-On

When choosing for Pass-Through Authentication (PTA), with or without Seamless Single Sign-On, organizations most likely have the following situation:

  • A federated system, like e.g. ADFS, is not in place
  • On-premises passwords are not allowed to be stored in Azure AD in any form
  • Passwords policies should also be governed by the on-premises AD and not by Azure AD

If this is the situation or are the requirements, then most likely an organization is using PTA. With PTA, custom DNS domains in Azure AD are configured as managed, but authentication is still not done by Azure AD. PTA is not exactly something like federated SSO, but it does have some similar behavior. When PTA is enabled, Azure AD knows that authentication must be redirected towards the on-premises AD. To make sure “something” on-premises knows how to handle that authentication request, a so called PTA agent is used. After enabling PTA through AADC, the AADC server hosts the first PTA agent. You can install additional PTA agents on additional servers to support the authentication redirection load from Azure AD.

So, in this case, Azure AD depends on the PTA agents and the PTA agents depend on the directory service (e.g., AD). Looks very similar to “Federated SSO” doesn’t it? In the case of a ransomware attack against the directory service (e.g., AD), authentication against Azure AD DOES NOT work anymore.

What can you do about this? Well, the initial thought could be again to “fix” the directory service (e.g., AD). Unfortunately, as before, that can take some serious time, especially if it is too complex or worse if no backups are available. OK, but is there a backup authentication like with “Federated SSO”. Well, the answer is again PHS. But wait!!! You chose PTA because you did not want to have any form of your passwords in Azure AD, and as backup you want to use PHS. First of all, that is not even possible. And if it were possible you would be using an implementation that contradicts itself. Are you also aware that ANY server with a PTA agent, must be considered as a Tier0 server? Trust me, servers with PTA agents belong in Tier0!!!

MY RECOMMENDATION: do you have and use PTA? Then get rid of it and start using PHS AS SOON AS POSSIBLE. You may not want to have your passwords in Azure AD because you think it is a risk, right? Think about the risk and impact on your users when literally not a single user would be able to authenticate, because you chose PTA! The problem with PTA is that many think about the requirements as listed earlier, but not many think about the consequences when a ransomware attack occurs. NOT using PTA, but rather PHS instead, this will save your and your organizations bacon big time with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.3] Password Hash Synchronization (PHS), with or without Seamless Sign-On

So if you are or not using “Federated SSO”, and for sure not PTA, then you must be using PHS actively or have it as a backup authentication mechanism. PHS is the best option when not having a federated system and not caring about any form of passwords being stored in Azure AD. There is even a third reason why you would want to have PHS. If you want to use the leaked credential feature of Azure AD, you MUST have PHS enabled, whether or not it is being used actively.

By default with PHS, all synched (user) accounts are in scope of synching their password hash to Azure AD. Although it is possible to only scope PHS to a specific set of groups (done through scoped sync rules in AADC), I highly DO NOT recommend that when we are talking about regular users using online services in or through Azure AD. The whole idea is about being able to use online services in or through Azure AD, when your on-premises AD has been burned to the ground due to a ransomware attack. If you think it won’t happen to you, think again. Todat, it is more about “when”, then “if”.

MY RECOMMENDATION: if you are already using PHS, that means you have chosen wisely. GOOD FOR YOU! With regards to this, there is not much extra what you can do. Just make sure it scopes your complete user population, and not just a part of it.

The moral of this story therefore is:

  • DO NOT use Pass-Through Authentication (PTA)
  • DO NOT use Pass-Through Authentication (PTA)
  • DO NOT use Pass-Through Authentication (PTA)
  • DO NOT use Pass-Through Authentication (PTA)
  • DO NOT use Pass-Through Authentication (PTA)
  • DO NOT use Pass-Through Authentication (PTA)
  • At least enable Password Hash Sync (PHS) as a backup authentication if you are actively using a federation system for federated SSO against Azure AD
  • Migrate to start using Password Hash Sync (PHS) as the primary authentication

PS: make sure you update your stakeholders, management and security officers about this, and take appropriate action as needed!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), AuthN, Azure AD / Office 365, Azure AD Connect, Forest Recovery, Ransomware, Windows Azure Active Directory | Tagged: , , , , , , , , | Leave a Comment »

(2022-07-05) Re-Awarded for the 17th Time – MVP Enterprise Mobility (Identity And Access)

Posted by Jorge on 2022-07-20


You might ask yourself why this post now and not earlier when I got the mail? Well, when you write the post, get distracted due to other activities, forget to press PUBLISH, and some time later, as in now, you realize, this was never sent. Crap! That’s stupid. Well, better late then never. Here it goes.

Here we go again! 17 years of community service!

On July 5th I received an e-mail from Microsoft I was re-awarded again with the MVP Award for Enterprise Mobility in the Identity And Access Area. This year is the 17th time I have received this award!

Let’s go for yet another year! Whooohoooo!

Roughly translated Microsoft is writing:

Once again, we are pleased to present the 2022-2023 Microsoft Most Valuable Professional (MVP) Award in recognition of your outstanding leadership in tech communities. We appreciate your outstanding contributions to the following tech communities over the past year:

  • Enterprise Mobility

17x

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Microsoft, MVP | Tagged: , , , | 1 Comment »

(2022-07-04) Presenting At The Troopers 2022 Conference

Posted by Jorge on 2022-07-04


Last week I delivered a session about AD Disaster Recovery after a ransomware attack at the Troopers 2022 conference in Heidelberg Germany. The session was a blast!

I was really happy to see the room was packed with people, meaning there was much interest in listening what I had to say. The interaction with the attendees was great, people were taking notes, taking pictures and asking questions during and afterwards. Everything a presenter can wish for. Wow!

If you are interested in having a peek at the slides I used, you can find those through the following link:

Resurrecting After A Ransomware Attack – Be Secure, And Prepared!

Some time later the recording of the session is available on the Troopers Youtube channel

Have questions? Want a demo of the Semperis Disaster Recovery solution? Just let me know!


#DisasterRecovery #Semperis #Troopers

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Conferences, Forest Recovery, Security | Tagged: , , | Leave a Comment »

 
%d bloggers like this: