————————————————————————————————————————————————————- 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/ ###################
————————————————————————————————————————————————————- 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/ ###################
Since the last time, the script was published, the following changes were made:
v3.4, 2023-03-04, Jorge de Almeida Pinto [MVP-EMS]:
– Bug Fix: The PowerShell CMDlets from the ActiveDirectory module DO recognize the 2016 FFL and DFL. The script DOES NOT use those anymore, but instead uses S.DS.P.. The issue appears to be that MSFT did update the ActiveDirectory PowerShell module to recognize the 2016 FFL/DFL, but they apparently did not update the S.DS.P. DLLs to do the same. The script itself now detects this and reports the correct FFL/DFL when it is 2016
–
HAVE FUN!
–
PS: Got any feedback or request, please use Github to report bugs or requests! Thanks!
–
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/ ###################
Compared to the previous versions, this new version has many new updates and new features. It took some serious time to code everything, and also to test all scenarios I could think off. I deem it ready to be release to the public for all the benefit from!
Merry Christmas all, and sorry it took so long to release this. Hope it helps to stay secure and it makes your life easier!
Since the last time, the script was published, the following changes were made:
v3.3, 2022-12-20, Jorge de Almeida Pinto [MVP-EMS]:
Bug Fix: updated the attribute type when specifying the number of the AD domain instead of the actual FQDN of the AD domain
v3.2, 2022-11-05, Jorge de Almeida Pinto [MVP-EMS]:
New Feature: Adding support for scheduled/automated password reset of KrbTgt account password for either all RWDCs, all individual RODCs or specific RODCs
New Feature: Added mail function and parameter to mail the log file for review after execution with results
New Feature: Adding support for signed mail
New Feature: Adding support for encrypted mail
Bug Fix: Minor textual fixes
Bug Fix: fix an issue where one confirmation of continueOrStop would be inherited by the next
Bug Fix: fix an issue where the forest root domain would always be chosen as the source for replication and GPOs instead of the chosen AD domain when using custom credentials. This caused replicate single object to fail and for the determination of the Kerberos settings in the resultant GPO
Code Improvement: Added function getServerNames to retrieve server related names/FQDNs
Code Improvement: Added support for disjoint namespace, e.g. AD domain FQDN = ADDOMAIN.COM and DCs FQDN for that AD domain = .SOMEDNSDOMAIN.COM
Code Improvement: Removed ALL dependencies for the ActiveDirectory PoSH module and replaced those with alternatives
Code Improvement: Redefinition of tables holding data for processing
Code Improvement: Upgraded to S.DS.P PowerShell Module v2.1.5 (2022-09-20)
Improved User Experience: Added the NetBIOS name of the AD domain to the list of AD domains in an AD forest
Improved User Experience: Added the option to the function to install required PoSH modules when not available
Improved User Experience: Added support to specify the number of an AD domain in the list instead of its FQDN
v3.1, 2022-06-06, Jorge de Almeida Pinto [MVP-EMS]:
Improved User Experience: The S.DS.P PowerShell Module v2.1.4 has been included into this script (with permission and under GPL license) to remove the dependency of the AD PowerShell Module when querying objects in AD. The ActiveDirectory PowerShell module is still used to get forest, domain, and domaincontroller information.
Improved User Experience: Removed dependency for port 135 (RPC Endpoint Mapper) and 9389 (AD Web Service)
Bug Fix: Getting the description of the Test KrbTgt accounts in remote AD forest with explicit credentials to compare and fix later
Code Improvement: In addition to check for the correct description, also check if the test KrbTgt accounts are member of the correct groups
Code Improvement: Updated function createTestKrbTgtADAccount
Bug Fix: Minor textual fixes
v3.0, 2022-05-27, Jorge de Almeida Pinto [MVP-EMS]:
Bug Fix: Changed variable from $pwd to $passwd
Bug Fix: Variable used in single-quoted string. Wrapped in double-quote to fix
Bug Fix: Fix missing conditions and eventually credentials when connecting to a remote untrusted AD forest
Code Improvement: Minor improvements through scripts
Code Improvement: Changed variable from $passwordNrChars to $passwdNrChars
Code Improvement: Updated function confirmPasswordIsComplex
Code Improvement: Instead of assuming the “Max Tgt Lifetime In Hours” And the “Max Clock Skew In Minutes” is configured in the Default Domain GPO policy (the default) It now performs an RSoP to determine which GPO provides the authoritative values, and then uses the values from that GPO
Code Improvement: Added check for required PowerShell module on remote RWDC when running Invoke-Command CMDlet
Code Improvement: Added function ‘requestForAdminCreds’ to request for admin credentials
Improved User Experience: Specifically mentioned the requirement for the ADDS PoSH CMDlets and the GP PoSH CMDlets
Improved User Experience: Checking AD forest existence through RootDse connection in addition to DNS resolution
Code Improvement: Added a variable for connectionTimeout and changed the default of 500ms to 2000ms
v2.9, 2021-05-04, Jorge de Almeida Pinto [MVP-EMS]:
Improved User Experience: Added additional info and recommendations
New Feature: Added function to check UAC elevation status, and if not elevated to start the script automatically using an elevated PowerShell Command Prompt
–
HAVE FUN!
–
PS: Got any feedback or request, please use Github to report bugs or requests! Thanks!
–
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/ ###################
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:
Federated SSO
Pass-Through Authentication (PTA), with or without Seamless Sign-On
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/ ###################
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:
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/ ###################
HIP 2021 starts tomorrow (Wednesday, December 1st)!
You can catch me going LIVE at #HIP2021 on December 2nd (Thursday) at 10:30am – 11:30am EST (16:30pm – 17:30pm CET) as I join in on the conversation about the hybrid identity world with my session, “Resurrecting After A Ransomware Attack – Be Secure, And Prepared!”!
You can still register for FREE using the following link:
————————————————————————————————————————————————————- 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/ ###################
This guide contains best-practice recommendations for recovering an Active Directory forest, if forest-wide failure has rendered all domain controllers in the forest incapable of functioning normally. The procedure steps in this guide, which you must customize for your particular environment, describe how to recover the entire Active Directory forest to a point in time before the critical malfunction. They also ensure that none of the restored domain controllers replicates from a domain controller with potentially dangerous data.
–
The procedures apply to Active Directory Domain Services (AD DS) in Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, and the Active Directory directory service in Windows Server 2003.
–
REMARK: Remember that this is a general guide to help you to create your own forest recovery for your own environment. No forest recovery plan from one environment can be fully used in another environment without customizations. Also remember it is not just about technology. When creating a forest recovery plan take everything into account that is specific to your environment such as for example location of IT staff, communications, logistics, procedures, security, etc. And when you do create a forest recovery plan that is specific to your environment make sure to keep it up-to-date, as your environment changes, and also make sure to perform periodic “fire-drills”. Those fire-drills help you to see what may need to change in the plan and it also keeps the plan as fresh as possible in the minds of everyone involved.
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
Jorge's Quest For Knowledge! 