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 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/ ————————————————————————————————————————————————————- ########################### Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ################### ————————————————————————————————————————————————————-
About a month or so I blogged about the ZeroLogon vulnerability. Check it out HERE
Now why is this all important? I think I can say this is one of meanest vulnerabilities that I have seen for which you can loose control of your AD. Mitigation is quite easy through a number of steps, being:
Install at least the august patch on at least ALL your DCs if you have not done that already. You did not do this yet? Seriously? Living under a stone? Remember: ANYONE on your network that can communicate with your DC has the ability to own and control your AD domain/forest!
Monitor the System Event Log of ALL your DCs for event ID 5829, which is whenever a vulnerable Netlogon secure channel connection is used and allowed. TIP: to ease this, use Azure Log Analytics which helps you get all the information in one place! Then in Azure Log Analytics, you can use the KQL query displayed below, which will give you all the servers and the number of times it established a vulnerable Netlogon secure channel connection
If ANY SYSTEM still uses vulnerable netlogon connections, EITHER…
Patch/fix software/firmware if available (preferred!)
If a fix is not available immediately because the vendor is working on it, create a security group in AD, then use that security group and make all the systems, for which a fix is not yet available, a member of the security group. Then in the policy “Computer Configuration > Windows Settings > Security Settings > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections” specify that security group as the exception list
When ALL SYSTEMS previously using vulnerable netlogon connections, are either fixed/updated or configured as exception, enable enforcement mode as explained here
Monitor the System Event Log of ALL your DCs for event ID 5827, 5828, 5830, 5831 and take action as needed. Again, Azure Log Analytics which helps you get all the information in one place! You can use the KQL query displayed below
Event ID 5827: logged when a vulnerable Netlogon secure channel connection from a machine account is denied
Event ID 5828: logged when a vulnerable Netlogon secure channel connection from a trust account is denied
Event ID 5830: logged when a vulnerable Netlogon secure channel connection from a machine account is allowed due to the exception
Event ID 5831: logged when a vulnerable Netlogon secure channel connection from a trust account is allowed due to the exception
For all those systems in the exception group, chase the owners/vendors to fix/update the software before date XYZ (t.b.d. by yourself!) and tell them after that date you will remove the accounts as members and they will have issues
–
KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is allowed (Event ID 5829)
Event | where EventID == 5829 | project ParameterXml, TimeGenerated, EventID | parse ParameterXml with * ‘<Param>’ Computer ‘</’ * | summarize Count = count(EventID) by Client=Computer
–
KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is denied (Event ID 5827)
Event | where EventID == 5827 | project ParameterXml, TimeGenerated, EventID | parse ParameterXml with * ‘<Param>’ Computer ‘</’ * | summarize Count = count(EventID) by Client=Computer
–
KQL Query for when a vulnerable Netlogon secure channel connection from a trust account is denied (Event ID 5828)
Event | where EventID == 5828 | project ParameterXml, TimeGenerated, EventID | parse ParameterXml with * ‘<Param>’ Computer ‘</’ * | summarize Count = count(EventID) by Client=Computer
–
KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is allowed due to the exception (Event ID 5830)
Event | where EventID == 5830 | project ParameterXml, TimeGenerated, EventID | parse ParameterXml with * ‘<Param>’ Computer ‘</’ * | summarize Count = count(EventID) by Client=Computer
–
KQL Query for logged when a vulnerable Netlogon secure channel connection from a trust account is allowed due to the exception (Event ID 5831)
Event | where EventID == 5831 | project ParameterXml, TimeGenerated, EventID | parse ParameterXml with * ‘<Param>’ Computer ‘</’ * | summarize Count = count(EventID) by Client=Computer
–
Now. what’s the benefit of using this approach? There are more benefits!
Any update that is installed, which is released after February 9th 2021, will enable enforcement mode automatically. Any system NOT in the exception list will have issues!
The list of systems using vulnerable Netlogon secure channel connections, will not grow. The longer you wait the bigger the list might get. As YOU control the security group you can tell any owner requiring netlogon connections, to FIRST fix/update their software, which will allow the netlogon connection. Membership of the security group should decrease, NOT increase!
————————————————————————————————————————————————————- 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/ ————————————————————————————————————————————————————- ########################### Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ################### ————————————————————————————————————————————————————-
This is about a serious attack on AD, which is currently possible when not patched and configured correctly. A lot of information, and tooling, is on the internet available since a month or so about the ZeroLogin vulnerability and attack.
THIS A SERIOUS ONE! ACT NOW IF YOU HAVE NOT ALREADY!
Please use for your own environment or for any customer you work for or know about. This requires immediate attention for ANY AD domain/forest that you manage, as just patching is not enough.
In addition to patching, forcing secure RPC is ALSO required to prevent unsecure anonymous requests in any way. Not forcing secure RPC means that anyone on the network can easily take over the AD domain and become an full blown admin.
It is possible to check through event IDs who is currently using unsecure RPC. Those systems need to be patched ASAP.
As a temp measure it is possible to configure an exception for systems that need unsecure RPC. However, this must be a temp solution for those systems until updated to use secure RPC only. While that system uses unsecure RPC and is in the exception group, that system is a potential risk towards the AD as it can be misused to FULLY take over the AD forest/domain.
–
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/ ————————————————————————————————————————————————————- ########################### Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ################### ————————————————————————————————————————————————————-
A few years ago I wrote a PowerShell script/tool to notify users when their password was going to expire in Active Directory. The last update was almost 4 years ago. Some weeks ago I was inspired by someone that asked if the same script was also able to notify users, if their AD account was going to expire. The quick answer to that question was: “No, that was not possible”. Nevertheless, with that request in mind, I updated the PowerShell script to support expiry notifications for both account expirations and password expirations. And in addition to that I also updated many other things. Below is a list of of the updates I did:
v0.9, 2020-04-14, Jorge de Almeida Pinto [MVP-EMS]:
– Added support for account expiry notification in addition to password expiry notification
– In xml file changed main xml node name from ADPwdExpNotifyConfig to ADExpNotifyConfig
– In the xml file change fullPathToLogFile to logFileFolderPath
– In the xml file change fullPathToCSVFile to csvFileFolderPath
– Added features node section to xml for difference in enabled/disabled features
– Added featureName property to htmlBodyFile nodes in the XML
– Changed the fullPath property to htmlBodyFullPath in the htmlBodyFile nodes in the XML
– Added the attachedPictureFullPath property to the htmlBodyFile nodes in the XML
– Added accountExpiryNotificationEnabled and pwdExpiryNotificationEnabled property to searchBase nodes
– Added searchScope property (OneLevel Or Subtree) to searchBase nodes for more granualarity
– Added support for URL to request extend the accounts in the XML
– Added separate section per feature in the section daysBeforeWarn in the XML
– Changed the property name ‘min’ to ‘MinOrEqual’ in the section daysBeforeWarn in the XML
– Added support for Windows Server 2019 AD
– Added mail function with additional logic
– Added write to event log function
– Updated the Logging function
– Dropped support for custom config for logToScreen. By default will log to screen
– Dropped support for custom config for logToFile. By default will log to file
– Implement UAC check to make sure it does not break execution of the script
– All script issues are mailed to e-mail address specified in toSMTPAddressSupport and not toSMTPAddressInTestMode
– Bug fix: make sure that values exist in GPO and PSO
– Bug fix: make sure to Null values before reuse
– Checked script with Visual Studio Code and fixed all "problems" identified by Visual Studio Code
– Code improvements/optimization throughout the code
– Added more comments
– added html body example for account expiry in US and NL language
– Updated the output with different colors
– Updates NOTES section
–
WARNING: If you are using an older version of the script, you need to migrate the settings in your current XML configuration file to the new XML configuration. DO NOT just replace the PowerShell script and execute it as that will not work. Look at the change history to see what changed!
Got feedback? Please let me know through Github. Thanks!
–
PS: It is on my list to build a similar script for Azure AD accounts
–
Enjoy and cheers!
–
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/ ————————————————————————————————————————————————————- ########################### Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ################### ————————————————————————————————————————————————————-
Since the last time, the script was published, the following changes were made:
v2.8, 2020-04-02, Jorge de Almeida Pinto [MVP-EMS]:
– Fixed an issue when the RODC itself is not reachable/available, whereas in that case, the source should be the RWDC with the PDC FSMO
– Checks to make sure both the RWDC with the PDC FSMO role and the nearest RWDC are available. If either one is not available, the script will abort
v2.7, 2020-04-02, Jorge de Almeida Pinto [MVP-EMS]:
– Added DNS name resolution check to the portConnectionCheck function
– To test membership of the administrators group in a remote AD forest the "title" attribute is now used instead of the "displayName" attribute to try to write to it
– Removed usage of $remoteADforest variable and only use the $localADforest variable
– Removed usage of $remoteCredsUsed variable and only use the $adminCrds variable (Was $adminCreds)
– Added a warning if the special purpose krbtgt account ‘Krbtgt_AzureAD’ is discovered in the AD domain
– If the number of RODCs in the AD domain is 0, then it will not present the options for RODCs
– If the number of RODCs in the AD domain is 1 of more, amd you chose to manually specify the FQDN of RODCs to process, it will present a list of RODCs to choose from
– Operational modes have been changed (WARNING: pay attention to what you choose!). The following modes are the new modes
– 1 – Informational Mode (No Changes At All)
– 2 – Simulation Mode | Temporary Canary Object Created To Test Replication Convergence!
– 3 – Simulation Mode | Use KrbTgt TEST/BOGUS Accounts – No Password Reset/WhatIf Mode!
– 4 – Real Reset Mode | Use KrbTgt TEST/BOGUS Accounts – Password Will Be Reset Once!
– 5 – Simulation Mode | Use KrbTgt PROD/REAL Accounts – No Password Reset/WhatIf Mode!
– 6 – Real Reset Mode | Use KrbTgt PROD/REAL Accounts – Password Will Be Reset Once!
– When choosing RODC Krb Tgt Account scope the following will now occur:
– If the RODC is not reachable, the real source RWDC of the RODC cannot be determined. In that case, the RWDC with the PDC FSMO role is used as the source for the change and replication
– If the RODC is reachable, but the real source RWDC of the RODC is not reachable it cannot be used as the source for the change and replication. In that case, the RWDC with the PDC FSMO role is used as the source for the change and replication
– Sections with ‘#XXX’ have been removed
– Calls using the CMDlet ‘Get-ADReplicationAttributeMetadata’ (W2K12 and higher) have been replaced with .NET calls to support older OS’es such as W2K8 and W2K8R2. A function has been created to retrieve metadata
– Some parts were rewritten/optimized
v2.6, 2020-02-25, Jorge de Almeida Pinto [MVP-EMS]:
– Removed code that was commented out
– Logging where the script is being executed from
– Updated the function ‘createTestKrbTgtADAccount’ to also include the FQDN of the RODC for which the Test KrbTgt account is created for better recognition
– In addition to the port 135 (RPC Endpoint Mapper) and 389 (LDAP), the script will also check for port 9389 (AD Web Service) which is used by the ADDS PoSH CMDlets
– Updated script to included more ‘try/catch’ and more (error) logging, incl. line where it fails, when things go wrong to make troubleshooting easier
–
Have fun!
–
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/ ————————————————————————————————————————————————————- ########################### Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ################### ————————————————————————————————————————————————————-