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!

(2020-04-04) Azure AD Connect v1.5.18.0 Has Been Released

Posted by Jorge on 2020-04-04


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect" (Always The Latest Downloadable Version Only!)

IMPORTANT: In one environment I upgraded from Azure AD Connect 1.4.38.0. I noticed that it triggered a Full Import on the AAD MA/Connector, and it also triggered a Full Sync on both the AD and AAD MA/Connector. Since the full imports/syncs may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

Azure AD Connect: Version Release History

1.5.18.0

Released: 4/2/2020

Released for download. Not available for auto-upgrade

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Functional changes ADSyncAutoUpgrade

    • Added support for the mS-DS-ConsistencyGuid feature for group objects. This allows you to move groups between forests or reconnect groups in AD to Azure AD where the AD group objectID has changed, e.g. when an AD server is rebuilt after a calamity. For more information see Moving groups between forests.
    • The mS-DS-ConsistencyGuid attribute is automatically set on al synced groups and you do not have to do anything to enable this feature.
    • Removed the Get-ADSyncRunProfile because it is no longer in use.
    • Changed the warning you see when attempting to use an Enterprise Admin or Domain Admin account for the AD DS connector account to provide more context.
    • Added a new cmdlet to remove objects from the connector space the old CSDelete.exe tool is removed, and it is replaced with the new Remove-ADSyncCSObject cmdlet. The Remove-ADSyncCSObject cmdlet takes a CsObject as input. This object can be retrieved by using the Get-ADSyncCSObject cmdlet.

    Fixed issues

    • Fixed a bug in the group writeback forest/OU selector on rerunning the Azure AD Connect wizard after disabling the feature.
    • Introduced a new error page that will be displayed if the required DCOM registry values are missing with a new help link. Information is also written to log files.
    • Fixed an issue with the creation of the Azure Active Directory synchronization account where enabling Directory Extensions or PHS may fail because the account has not propagated across all service replicas before attempted use.
    • Fixed a bug in the sync errors compression utility that was not handling surrogate characters correctly.
    • Fixed a bug in the auto upgrade which left the server in the scheduler suspended state.

    I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle! I do not have auto-upgrade enabled, therefore unfortunately I cannot say anything about this version.

    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

    (2020-04-02) Migrated Code/Scripts From Technet Script Gallery To Github

    Posted by Jorge on 2020-04-02


    If you did not know already Microsoft will be retiring Technet Script Gallery.  More information here: https://docs.microsoft.com/en-us/teamblog/technet-gallery-retirement

    Currently it is in read-only mode, which means you can edit existing contributions as an owner, but you will not be able to add new contributions. In June 2020 Microsoft will shut it down, therefore if you have your code stored there, make sure to get it and migrate it to Github. If you need scripts from it, go and get those script before the shutdown.

    All my code/scripts is still available in Technet Script Gallery, but I also already migrated it to Github into different public repositories.

    Currently I have the following public repositories:

    On my blog I have created a new page called “Code/Scripts”, which is accessible from the main page of my blog.

    image

    Figure 1: Main Page Bar

    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Blog, Tooling/Scripting | Leave a Comment »

    (2020-02-14) Creating An HTML Report Of All Password And Account Lockout Policies In The AD Forest

    Posted by Jorge on 2020-02-14


    It was one of those days. Auditors came in to audit stuff. One of the questions was to produce evidence about the password and account lockout policy in the default domain policy. Those guys are probably still living in the Windows Server 2003 ages as with Windows Server 2008 and later so called Password Settings Objects (PSO) are supported where you can have as many password and account lockout policies as you see fit for your environment. For example, a PSO for regular users, one for regular service accounts and one or more your admin accounts.

    Read more about it:

    On of the environments I work with has multiple AD domains and each AD domain has multiple PSOs. Creating a report with all the settings is quite painful, unless you use PowerShell! Then it is as easy as taking candy from your kids! Smile

    So how do you make this repeatable and at the same time keep the auditing guys happy with a nice overview? By using a report similar to:

    image

    Figure 1: An HTML Report Of All Password And Account Lockout Polices

    The script that produces that? get it from here: https://gallery.technet.microsoft.com/Building-A-Password-And-d18f991f

    Example report: Password And Account Lockout Policy HTML Report (Example)

    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Active Directory Domain Services (ADDS), Fine Grained Password Policies, Passwords | Leave a Comment »

    (2020-02-11) Fox-IT Report Available On Cyber Attack Against University Of Maastricht

    Posted by Jorge on 2020-02-11


    On December 23rd 2019 a cyber-attack occurred against the University of Maastricht. Fox-IT, a Dutch security company and part of the NCC Group, supported the University of Maastricht and in the end wrote a report with the findings. The University of Maastricht made that report publicly available so that others could learn from it. Kudos to the University of Maastricht for sharing this information.

    The report is in Dutch and can be found through: https://www.maastrichtuniversity.nl/file/49715/download?token=B0jN2wyV

    If you do not understand Dutch, or do not want to read the full report, below you can find an extract in English of that report. Please be aware that the text below is a summary of the Dutch report written by Fox-IT. This summary may lack the required (detailed) context that is available in the report.

    High Level:

    • Cyber-attack on December 23rd 2019
    • Infrastructure of 1647 Linux/Windows Servers and 7307 workstations. Attack against part of the infrastructure, 267 servers in the AD domain (e.g. domain controllers, e-mail servers, file servers, backups servers)
    • Attacker focused on encrypting data in the AD domain to demand ransom in the end. Part of systems were compromised, incl. (online) backups

    Environment:

    • University of Maastricht
    • Public organization, with 4500 employees, 18000 students and 70000 alumni
    • Infrastructure contains multiple server (types) and workstations that are not (fully) controlled by central IT
    • Part of the infrastructure centrally managed and part decentrally managed by faculties, and both connected to central network
    • Workstations are desktops, laptops and VDIs. VDIs accessible through thin-clients and browsers

    Lessons Learned

    • Multiple phishing mail variants received. Because phishing mails looked similar, one variant did not get enough attention. Better detection needed
    • Signed macros only. Phishing mails contained links to Excel files with unsigned macros
    • Improved processes for vulnerability and patch management. Keep systems up-to-date and make sure updates are installed successfully. Attackers used vulnerabilities in software (Eternal Blue Exploit). (e.g. One patch was not installed because its installation had failed.)
    • Better segmentation of the AD domain (tiering and delegation) and implement secure configurations as much as possible, and get rid of insecure configurations. Default domain admin account was used for work on regular servers (was against existing policy!). Due to a compromised server and usage of a very powerful account on that server, AD domain was compromised too. Malware and ransomware got installed after that using default domain admin account
    • Better segmentation of the network itself. Current network has multiple VLANs, but still too open. Due to that openness of the network it was still too easy to move around. Stricter segmentation would have made it more difficult to move around by the attacker
    • (Better) 24/7 monitoring/logging through SIEM and SOC. Signals with unusual patterns, peak activities and/or high risks need to be filtered and detected better/easier/earlier and become more visible from the huge amount of data (per second 30000 breach attempts blocked, 1400 malware attacks stopped, thousands of signals a day in multiple logs). Implementation of end-point monitoring and network sensors started to detect traffic and distinguish between regular and malicious traffic (both incoming as lateral movement) (was already planned before breach to do so)
    • Up-to-date and clean CMDB. During recovery lots of time was invested to determine impact on systems/environment. View on active systems and decommissioned systems was not good enough, which made it more difficult to get understanding of actual status
    • Multiple backups, both online for quick recovery as needed and offline availability of backups to make sure these remain uncompromised. Due to having only online backups for quick recovery when system(s) became unavailable, the backups were also encrypted
    • Make sure to have incident response plans for different scenarios and keep it up-to-date. On planned basis, practice different crisis scenarios and improve plans as needed
    • Increase security awareness of both employees as students

    More details (not in structured order):

    • Compromised system is system with attacker activity of malware traces. 269 servers were determined to be compromised
    • Compromised account is account used by attacker, after forensic analysis. 5 accounts were determined to be compromised
    • Next to Windows systems, Linus and OS X systems are in use that were not touched by the attack. Attack focus was Windows servers
    • 2 phishing e-mails opened on October 15th and 16th 2019. Phishing mails contained links to Excel file with Macro that downloaded malware (SDBBot) from server on internet.
    • Multiple systems compromised between October 16th 2019 and December 23rd 2019
    • On November 21st 2019 attacker gained access to infrastructure through a server that was missing security updates (vulnerable for Eternal Blue exploit)
    • On December 23rd 2019, "Clop-ransomware" was deployed to 267 Windows Servers. "Clop-ransomware" uses RC4 encryption algorithm. RC4 key is generated randomly per file and encrypted with an RSA 1024 bit public key. Only the attacker has the private key. All encrypted file received the “.CIop” extension and in every folder the file “CIopReadMe.txt” with instructions was added
    • After thorough analysis of the breach, ransom was paid on December 30th 2019
    • Traces were found that attacker gained information amongst others about topology, servers, usernames and passwords
    • Carbon Black was installed by security company and used to get insights on traffic and activity. Installation was initiated on compromised servers followed by non-compromised servers and workstations (more than 90% of systems were covered by this tool)
    • Focus was on quick recovery of functionality, but also safeguarding all kinds of research information to be able to perform forensic analysis at a later stage
    • With forensic analysis, attack path and scope or attacker was made visible
    • Counter measures to stop attack (amongst others): close network traffic to and from internet, and to and from WIFI networks, reset passwords of all accounts (admin, service, regular)
    • Network traffic gradually being allowed again after setting up monitoring/sensors
    • Definition of so called crown jewels determine the priority of recovery
    • Malware communicated on regular basis with home server (every 15 minutes) and registered itself to become and remain persistent, event after reboots. Through this malware other tools (Meterpreter) were used for interaction. Meterpreter was installed on other servers (2x Windows Server 2003 R2 lacking the MS17-010 patch, 1x Windows Server 2012R2 and 1x unnamed), most likely through the Eternal Blue exploit as those servers were vulnerable for it. Other unnamed server was not vulnerable for Eternal Blue exploit, but still got infected somehow. Patch KB4525243 prevents the Eternal Blue exploit
    • PowerSploit was used for reconnaissance of systems/network and vulnerabilities
    • PingCastle was used to get graphical view of AD structure and misuse weak configurations
    • Cobalt Strike with mimikatz was used
    • SAGE.EXE was “installed” on 4 servers and was used to distribute ransomware and at the same time turn off Windows Defender, all through the use of the default domain admin account. On one server antivirus detected and removed SAGE.EXE. In the end attacker removed antivirus and reinstalled SAGE.EXE. Later antivirus was removed from other servers too
    • Attacker activity was already detected in earlier stage and send to central log server. Unfortunately those detections were not proactively taken care of or actioned upon (Windows Defender detected, removed (and logged this) PowerSploit) (Antivirus multiple times detected and logged use of Cobalt Strike and Mimikatz, but did not stop due to “observer/audit only mode”)

    Info about attacker:

    • Group “TA505” or “GraceRAT” or “Dridex-RAT-Group”
    • Use Clop ransomware
    • Targets orgs with AD
    • 150 victim orgs in 2019
    • In period 2014-2017 attacker focused on attacking orgs in financial sector in EU as USA
    • In period 2017-2019 attacker focused on attacking financial orgs with creditcard issuing systems in South- and Central America, Africa and Central and Southeast Asia.
    • Attacking orgs in financial sector still takes place

    Modus operandi attacker:

    • Infect systems through phishing mails
    • Identify org
    • Lateral movement within network
    • Remove and encrypt backups
    • Deploy ransomware on as many systems as possible
    • Demand ransom per e-mail (amount depends on size of org)

    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Cyber Attack, Day-To-Day Stuff, IT News | Leave a Comment »

    (2020-01-30) Deprecation Of Azure AD Connect Versions

    Posted by Jorge on 2020-01-30


    Starting on November 1st, 2020, Microsoft will begin implementing a deprecation process whereby versions of Azure AD Connect that were released more than 18 months ago will be deprecated. At that time Microsoft will begin this process by deprecating all releases of Azure AD Connect with version 1.1.751.0 (which was released on 4/12/2018) and older, and Microsoft will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.

    You need to make sure you are running a recent version of Azure AD Connect to receive an optimal support experience. If you run a deprecated version of Azure AD Connect you may not have the latest security fixes, performance improvements, troubleshooting and diagnostic tools and service enhancements, and if you require support Microsoft may not be able to provide you with the level of service your organization needs.

    If you have enabled Azure AD Connect for sync you will soon automatically begin receiving Health notifications that warn you about upcoming deprecations when you are running one of the older versions.

    Please refer to this article to learn more about how to upgrade Azure AD Connect to the latest version

    In other words: if you are still running the old stuff, start planning to get rid of it! There is NO excuse! Smile

    Azure AD Connect: Version release history

    ————————————————————————————————————————————————————-
    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

    (2020-01-23) Smartcard/PIN Better Than Username/Password?

    Posted by Jorge on 2020-01-23


    Think username/password is a bad thing (both "something you know"). Using Smartcard/PIN ("something you know" & "something you have") instead for interactive logon? It is a bit better, but if hacker has compromised your computer and is using e.g. Mimikatz, you’re still screwed! So, the answer is: “no it is not better”

    image

    Figure 1: Mimikatz Output Displaying Clear Text PIN Of The Smart Card

    Move away from it and go passwordless! Whatever you choose the secrets must be stored and accessed securely and there must be an “inaccessible” factor (e.g. biometric) or a dynamic factor (e.g. OTP, choosing value, etc.)

    ————————————————————————————————————————————————————-
    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/ ###################
    ————————————————————————————————————————————————————-

    Posted in Active Directory Domain Services (ADDS), AuthN | Leave a Comment »

     
    %d bloggers like this: