Understanding Active Directory (AD) permissions is vital for cybersecurity, compliance and business continuity. In this blog, we’ll be going over, at a high level, how Active Directory permission are applied in a domain and how to view them natively. The most common way to apply Active Directory permissions is through the tool Active Directory Users and Computers (ADUC). There are two ways in ADUC to apply permissions: This blog post will cover both of these options.

Since 2014, the National Institute of Standards and Technology (NIST), a U.S. federal agency, has issued guidelines for managing digital identities via Special Publication 800-63B. The latest revision (rev. 3) was released in 2017, and has been updated as recently as 2019. Revision 4 was made available for comment and review; however, revision 3 is still the standard as of the time of this blog post.

This post walks you through the steps of setting up a point-to-site VPN connection from a Windows server running Netwrix StealthAUDIT, so you can discover and monitor all your Azure SQL databases.

Active Directory user objects possess a number of logon metadata attributes that are valuable for Active Directory audit reporting and administration. For example, they are commonly used to identify user accounts that have been inactive for a significant period, or as “stale” accounts. However, each logon metadata attribute has some unique behaviors that need to be understood.

One critical way that attackers gain access to an IT environment and escalate their privileges is by stealing user password hashes and cracking them offline. We covered a method for harvesting service account passwords in our post on Kerberoasting. Here we will explore a technique that works against certain user accounts, AS-REP Roasting. We’ll cover how adversaries perform AS-REP Roasting using the Rubeus tool and how you can defend your organization against these attacks.

Note: The examples in this post use apt commands, which are for Debian-based operating systems like Ubuntu, Kali and Mint. However, the examples have also been tested with yum/dnf commands for RPM-based distros like CentOS, Red Hat, Fedora and openSUSE.

Learning how attackers target weak domain account passwords is not enough for Active Directory security. Let’s look beyond domain accounts and understand the ways adversaries attack local accounts on Windows servers and desktops. For this post, we will focus on the most important local account: Administrator.

I was speaking with an Active Directory security engineer at a global pharmaceutical company recently, and I asked him the most classic question in the product management handbook: “What keeps you up at night?” So cliché (I know), but sometimes instead of an eye roll, you get a real gem, which is exactly what happened.

By default, when you create a new Internet Information Services (IIS) website, it’s open to everyone with anonymous access enabled — anyone can access and view the data being hosted by that site. Obviously, this is a security concern for most organizations. Indeed, I’m often asked by clients and colleagues how to lock down an IIS site so only the desired people can access it.