Active Directory

Disclaimer: I made this. It's free and open source. No ads, just clean, useful data provided in blog.

Here's a small PowerShell command/module I've written. It contains the following reports.

Usage:

Find-Events -Report ADGroupMembershipChanges -DatesRange Last3days -Servers AD1, AD2 | Format-Table -AutoSize

ReportTypes:

• Computer changes – Created / Changed – ADComputerCreatedChanged

• Computer changes – Detailed – ADComputerChangesDetailed

• Computer deleted – ADComputerDeleted

• Group changes – ADGroupChanges

• Group changes – Detailed – ADGroupChangesDetailed

• Group changes – Created / Deleted – ADGroupCreateDelete

• Group enumeration – ADGroupEnumeration

• Group membership changes – ADGroupMembershipChanges

• Group policy changes – ADGroupPolicyChanges

• Logs Cleared Other – ADLogsClearedOther

• Logs Cleared Security – ADLogsClearedSecurity

• User changes – ADUserChanges

• User changes detailed – ADUserChangesDetailed

• User lockouts – ADUserLockouts

• User logon – ADUserLogon

• User logon Kerberos – ADUserLogonKerberos

• User status changes – ADUserStatus

• User unlocks – ADUserUnlocked

DatesRanges are also provided. Basically what that command does it scans DC's for event types you want it to scan. It does that in parallel, it overcomes limitations of Get-WinEvent and generally prettifies output.

The output of that command (wrapped in Dashimo to show the data):

GitHub Sources:

Full article (usage/know-how):

The article describes the functionality of just one command but actually, PSWinReportingV2 is much more than that. There are also things I've not touched in the article but that should be a start. It's able to support any kind of Events from Event logs such as ADConnect, Hyper-V and other types of data. I just didn't have time to explain how to build configs for it and I don't work with Hyper-V or other systems to build them myself. If you know a lot about event logs and what to help to build prettified reports for more than Active Directory reach out.

hey hey,

usually i'm a lurker.

but because of recent events i have a simple question for you guys:

would you say active directory (building it from the scratch, security hardening, basic to advanced GPOs , DNS , printer server, fileserver etc). should be common knowledge for a sys-admin?

i debated many times with colleagues about it over the past years, but had recently a experience where a single sys-admin ran a productive structure with circa 20 pcs plus 5 printers for years without AD (i dont see a problem with it basically, atleast from the security side, but in this case the problem was that he simply wasn't able to build an AD, because he didn't know how / didn't even knew that it existed (that was my feel), so he had to do it the "classic way", and yes he did all of eventually changes locally on each PC!)

happy to read your opinions on this one :)

You don't. You fucking don't decentralise control over user access especially if you're a Microsoft shop and don't want to deal with the immense hassle that will be your life if you were to do away with Active Directory all together.

Fuck I hate ads

As stated in the title if anyone has any good resources they can link to I would appreciate it.

The ownership of AD seems to be underasked or I'm worthless at searching (sorry if that's the case). I wonder who manages/owns the AD in your company and your opinion on what team should? In my company the AD is run by the workplace team and supported by the security team. The workplace wants to get rid of the responsibility so it would be interesting to see how others handles this question.

Edit. Current headcount of the company is 5500 and it team around 100 with some functions outsourced.

Hi, former dude who is now a dude. This is just a friendly PSA to let y'all know to NEVER put sensitive information in your Active Directory description fields.

An attacker who has even the lowest level of access in Active Directory can dump all of that information with little effort, it's not safe or secure.

I know most of you will say, "What kind of idiot would ever put a password or social security number in an AD field?!" Well, I'll just say I've seen it more than once during pentests.

Also, don't circumvent your own corporate password policies!

If you want practice using AD in a virtual setting, how would you do it?

So I've been in a tech role for a few years now. Went from help desk to infrastructure architect/product owner. I was doing something in AD and saw the "save search" option. Went and played with that a bit and realized you don't have to navigate to the actual OU to see attribute editor. You can just create a saved search and always search a users name or ID to get to what you want.

Anyone have any other tips?

When I was first being introduced to AD and ADUC in very early 2000s, my mentors pronounced it as 'A Duke' so that's how I've always pronounced it. Honestly, it sounds so much better to me. When I hear 'A Duck', I'm reminded of a vulgar expression I used to hear a lot in the 80s and 90s..."well, f**k a duck!" Also, I'm tempted to make quacking noises.

It has come to my attention that most people probably say 'A Duck' but I'm wondering...Am I the only one that says 'A Duke'?

Was working on an issue for a user; they called in using this program called ResWare. We're going to call this user "Rani".

In ResWare, they export documents and such to MS office. This is pretty standard with pretty much any LOB programs that do reports/finances en masse. Okay, cool, traditional problem. Here we go, boys.

So she calls in telling me that she's having issues with opening documents in office. It was hard enough to understand with a combination of accent and the phone being muffled, but I like a challenge so let's see. I remote in to the machine and see the issue, office is asking for creds when logging in. Okay, so the product is unlicensed. Simple enough.

At this point, I had Rani log in. No good. Wouldn't take creds. Well, there could be a number of reasons for this but I don't feel like digging into them so I just had her try a few more times, same result. Okay, fine. I see how it is. Site uses O365 though, so let's see if they can even log into that.

So I had Rani log into this and it didn't work. Pass or username is no good. Ha. So it's a password problem. But it's never that simple. Here it comes. You can feel it. I felt it as soon as I saw those dreaded red letters.

Me: "All right! So it appears your password is wrong."

Rani: "It couldn't be. It was just working the other day."

Inner Me: "no. Stop. Don't do this to me, Rani. Don't. You're gonna make me get greasy with you."

Me: "I understand it may have been working the other day but sometimes this happens with O365 systems. Passwords expire or, for some random trick of the ether, they just stop working.

Okay, we all know passwords don't just "stop working", but most users don't inquire after that. I wish it would've been that simple.

Me: "Let me check something real quick for you..." *logs into O365 admin* "We may need to reset your password." *sees that account is synced with Active Directory. Victory, so they're using SSO.* "All right! So it seems your password is synced with AD, meaning they should all be the same. Try your computer login please."

Rani: i shouldn't have to do that. The passwords have always been different.

Inner Me: "I'm gonna have to do it to her. I'm REALLY gonna have to do it to her."

Me: "I understand that, but as of right now your account is synced with the server. This means that every password that is like that will be the same. Almost like one, big, easy to use system. Makes life much more streamlined for you."

Rani: "but I never had to do this before."

Me: "Let's try something..." *locks computer* "Login for me, please."

Rani logs in, after saying something about it. I noticed she typed in a stupid long password.

Me: "What password was that? The one you said your email pass was wasn't anywhere nearly as long as that."

Rani: "Yes, because the passwords are different."

The inner me at this point is furious like that character from Inside Out.

Me: "They're linked together, so let's try that." After she logged in, this verified her AD account wasn't locked

Pass didn't work in O365, I'm guaranteeing she half-assed it but whatever. I'm going to beat this issue to death if it kills me. Tried it several more times, no good.

Rani: "I don't know why this is taking so long. A previous tech from last week was able to do it in 2 seconds and it worked. I don't know why this is so difficult."

Inner Me: "Okay, so you're flipping telling me a tech did this LAST WEEK and did it completely wrong, which is why we're in this boat. I wonder who that was."

At this point she was getting that "you don't know what you're doing attitude" and I wasn't about to put up with that because it wouldn't have been good for either of us.

Me: "Okay, you know what..." *goes into O365 admin* "I'm going to reset your password in O365 here... and it'll work. Watch." *reset pass to what she wanted, had her log in and it worked fine* "Now look, here's what's going to happen. This account is going to work for an hour or two, maybe even a couple of days, BUT this system WILL sync back up to AD and your password WILL NOT WORK. All right?"

I suspected at this point she didn't want to talk to me anymore because she wouldn't hang around to test her original issue; not being able to send files from Resware to office because her products were unlicensed.

Rani: "I'll call you back if there are any other issues."

Me: "Mkay, here's your ticket number for if the issue reoccurs."

Then I proceeded to put in the internal notes about this foolish interaction because I'm not falling on that sword and having my own competency called into question. Nice enough lady to talk to, but as stubborn as a brick.

Hey there, former sysadmin turned pentester here. Recently, in almost every environment, I've been able to privesc from a regular user to Domain Admin using AD CS vulnerabilities.

I definitely recommend running or () to see if you can identify any vulnerabilities in your environment. As far as I know, this stuff won't come up on a Nessus scan. I know when I was a sysadmin I set this up insecurely (has now been fixed). However, AD CS is easy to set up without knowing some of the security implications of the configurations.

The guys over at Spectorops who came out with their paper on attacking AD CS () also have a good talk on "".

Edit: I linked both Certify and Certipy earlier. Certify is a windows application. Certipy is based on python. I prefer certipy. If you want to run certipy it’s pretty easy. One way is to setup a Kali VM. .

Then next through the Kali install. If it pulls dns and up from DHCP you should be good to go. After you’re in, open up a command prompt and type

pip3 install certipy-ad

Then run

certipy find -vulnerable -stdout -u lowprivuser@domain.local -p password

A user claimed he had successfully joined his private laptop to the Active Directory domain. I didn't believe him at first... I was wrong. Apparently, any authenticated user can add up to 10 new computers to an Active Directory domain. According to , this also applies to Windows Server 2008R2. I don't know if this still counts for later versions?

Anyway, I was baffled. Is this OK - or how should we deal with this?

Also found other articles on Technet and about this.

You're never too old to learn, I guess...

The sysadmin before me decided it would be a great idea to utilize a domain that we do not own as the domain used for AD and across all our domain controllers. I’ve reached out to the owner of the domain, but seeing that it is a three letter domain (ex. abc.com), it is highly sought after and they will not give it up easily.

Evidently, we have been using this domain for over a decade.

What would you recommend in this case, and what are the risks I should be aware of if we did not/cannot change the domain? Migrating to a domain we do own seems like a monumental task given the complexity of our current environment, so I’m just considering my options.

I wanted to introduce you today to my new PowerShell module. Actually a couple of them, and to remind you a bit about my other PowerShell modules. Hope you like this one. This PowerShell module is able to extract Active Directory data as can be seen below. If you want to find out more:

It covers usage, code explanation, examples, and a few other things. Generally all the know/how (no ads/no pay software). It's free and open source. All of it.

Links to sources:

• PSWinDocumentation.AD - - the module that provides all the Active Directory data as one command.

• Dashimo - - a module that is able to wrap that data into HTML

• Emailimo - - a module that is able to wrap that data into Email and send it over

• Documentimo - - a module that is able to wrap that data into WORD document (no word required)

• Excelimo - - a module that is able to wrap that data into EXCEL document

Example output

• HTML Version:

• DocX Version:

• Xlsx Version: (minimal)

Small code sample 1:

$Forest = Get-WinADForestInformation -Verbose -PasswordQuality
$Forest

Small code sample 2:

$Forest = Get-WinADForestInformation -Verbose -PasswordQuality
$Forest.FoundDomains
$Forest.FoundDomains.'ad.evotec.xyz'

Small code sample 3:

$Forest = Get-WinADForestInformation -Verbose -PasswordQuality -DontRemoveSupportData -TypesRequired DomainGroups -Splitter "`r`n"
$Forest

You can install it using:

Install-Module PSWinDocumentation.AD -Force

Datasets covered by PSWinDocumentation.AD

• ForestInformation

• ForestFSMO

• ForestGlobalCatalogs

• ForestOptionalFeatures

• ForestUPNSuffixes

• ForestSPNSuffixes

• ForestSites

• ForestSites1

• ForestSites2

• ForestSubnets

• ForestSubnets1

• ForestSubnets2

• ForestSiteLinks

• ForestDomainControllers

• ForestRootDSE

• ForestSchemaPropertiesUsers

• ForestSchemaPropertiesComputers

• DomainRootDSE

• DomainRIDs

• DomainAuthenticationPolicies

• DomainAuthenticationPolicySilos

• DomainCentralAccessPolicies

• DomainCentralAccessRules

• DomainClaimTransformPolicies

• DomainClaimTypes

• DomainFineGrainedPolicies

• DomainFineGrainedPoliciesUsers

• DomainFineGrainedPoliciesUsersExtended

• DomainGUIDS

• DomainDNSSRV

• DomainDNSA

• DomainInformation

• DomainControllers

• DomainFSMO

• DomainDefaultPasswordPolicy

• DomainGroupPolicies

• DomainGroupPoliciesDetails

• DomainGroupPoliciesACL

• DomainOrganizationalUnits

• DomainOrganizationalUnitsBasicACL

• DomainOrganizationalUnitsExtendedACL

• DomainContainers

• DomainTrustsClean

• DomainTrusts

• DomainBitlocker

• DomainLAPS

• DomainGroupsFullList

• DomainGroups

• DomainGroupsMembers

• DomainGroupsMembersRecursive

• DomainGroupsSpecial

• DomainGroupsSpecialMembers

• DomainGroupsSpecialMembersRecursive

• DomainGroupsPriviliged

• DomainGroupsPriviligedMembers

• DomainGroupsPriviligedMembersRecursive

• DomainUsersFullList

• DomainUsers

• DomainUsersCount

• DomainUsersAll

• DomainUsersSystemAccounts

• DomainUsersNeverExpiring

• DomainUsersNeverExpiringInclDisabled

• DomainUsersExpiredInclDisabled

• DomainUsersExpiredExclDisabled

• DomainAdministrators

• DomainAdministratorsRecursive

• DomainEnterpriseAdministrators

• DomainEnterpriseAdministratorsRecursive

• DomainComputersFullList

• DomainComputersAll

• DomainComputersAllCount

• DomainComputers

• DomainComputersCount

• DomainServers

• DomainServersCount

• DomainComputersUnknown

• DomainComputersUnknownCount

• DomainPasswordDataUsers

• DomainPasswordDataPasswords

• DomainPasswordDataPasswordsHashes

• DomainPasswordClearTextPassword

• DomainPasswordClearTextPasswordEnabled

• DomainPasswordClearTextPasswordDisabled

• DomainPasswordLMHash

• DomainPasswordEmptyPassword

• DomainPasswordWeakPassword

• DomainPasswordWeakPasswordEnabled

• DomainPasswordWeakPasswordDisabled

• DomainPasswordWeakPasswordList

• DomainPasswordDefaultComputerPassword

• DomainPasswordPasswordNotRequired

• DomainPasswordPasswordNeverExpires

• DomainPasswordAESKeysMissing

• DomainPasswordPreAuthNotRequired

• DomainPasswordDESEncryptionOnly

• DomainPasswordDelegatableAdmins

• DomainPasswordDuplicatePasswordGroups

• DomainPasswordHashesWeakPassword

• DomainPasswordHashesWeakPasswordEnabled

• DomainPasswordHashesWeakPasswordDisabled

• DomainPasswordStats

And just a small update on my Find-Events command... I've added one more report Organizational Unit Changes (move/add/remove). So the default list now covers:

• ADComputerChangesDetailed

• ADComputerCreatedChanged

• ADComputerDeleted

• ADGroupChanges

• ADGroupChangesDetailed

• ADGroupCreateDelete

• ADGroupEnumeration

• ADGroupMembershipChanges

• ADGroupPolicyChanges

• ADLogsClearedOther

• ADLogsClearedSecurity

• ADUserChanges

• ADUserChangesDetailed

• ADUserLockouts

• ADUserLogon

• ADUserLogonKerberos

• ADUserStatus

• ADUserUnlocked

• ADOrganizationalUnitChangesDetailed (added in 2.0.10)

I've also added Credentials parameter which should provide a way for you to use a command from normal user PowerShell prompt. If you have no clue about that command yet - have a read here: otherwise:

Update-Module PSWinReportingV2

Enjoy :-)

We have an Active Directory domain that is about to reach 50,000 users. When we built this domain over a decade ago, we built it with two on-prem DC's. We later added a DR site off-site at a server hosting facility, and that DR site has two additional DC's that replicate with the on-prem domain. I haven't thought about checking for any performance-related issues that might be caused by this volume of users so am curious about the following:

1. What kinds of issues might appear as a result of AD growth?

2. Is 50,000 users considered "too many" for two on-prem DC's (4 CPU, 16GB RAM each)?

3. What are the best ways to respond to those issues? Additional resources for existing DC's? or additional DC"s?

The Juicy part: Ubuntu machines can join an Active Directory (AD) domain at installation for central configuration. AD administrators can now manage Ubuntu workstations, which simplifies compliance with company policies.

Ubuntu 21.04 adds the ability to configure system settings from an AD domain controller. Using a Group Policy Client, system administrators can specify security policies on all connected clients, such as password policies and user access control, and Desktop environment settings, such as login screen, background and favourite apps.

Hi there,

Just been asked to create AD solution for 28+ million users. For some reason we have to have all valid users credentials in AD. Only going to be used external for authentication at the moment. I can see on that it should be possible but has anyone worked with this scale of users before? The most I've had on an AD before is about 2,000...

And yes, management says it has to be done this way.

Edit: Licensing on this thing looks like it'll be US$300K for just the External Connectors

Edit 2: Looks like will let me do this for free and still meet the security requirement. HA/Clustering looks interesting tho.

Edit 3: AD-LDS is not free for this use case :0(

Edit 4: Will report back when design and costing is done. Think it will be fine if just used for app authentication but more than 4GB RAM will be needed.

Hello, I've inherited an AD system where the previous sysadmins have all left the company or died. What's worse, the dead sysadmin was prone to install stuff,, make random edits, and not tell everyone, so nothing is documented and random stuff is not on default settings. We're currently on AD Domain level 2012 r2 (because said sysadmin hadn't really updated anything for a long while).

Onto the current issue, when I try to add a computer to the domain, I'm unable to, despite being a domain admin. The computer needs to be pre-created before it can be added. Where was this setting set and how do I change it? A google search has some people ask how to set it up this way, but the answers point to it being impossible, despite it being how my current environment is set up.

Any ideas on settings to check, or where to check to see how this was accomplished?

Can Active Directory Certificate Services (AD CS) behave like a third-party CA for domain-joined devices? In other words, can an AD CS issued cert be validated in the same manner as a commercial cert (however that works), or does an AD CS cert require it be added to the trusted root cert store on all computers?

A self-signed cert has to be manually added to the trusted root certificate store on all computers that leverage it, while a certificate issued by a commercial CA (e.g. DigiCert) is trusted automatically by way of the browser validating the cert using the CA's cert web services.

So where does AD CS fit in? My original understanding was that AD CS is like a commercial CA for your domain, and that any domain-joined device using a cert issued by AD CS would automatically trust it the same way it would trust a commercia cert. But I just read some Microsoft documentation that says you still have to manually add the AD CS issued cert to the trusted root cert store on all domain-joined devices. So do domain-joined devices not just automatically see that this is an AD CS cert and make a quick validation request to the AD CS services? And I'm being told by at least one vendor (Patch My PC) that their AD CS issued cert has to be added to both the Trusted Publishers and the Trusted Root Cert Store on each computer.

This is a hybrid position, requiring three days in the office located in Silicon Valley. A relocation and immigration package is offered.

Are you an Active Directory expert with a passion for automation and security? Do you thrive in a collaborative environment where you can partner with development and infrastructure teams to optimize systems and services?

If so, we have the perfect opportunity for you!

In this role, you will: Leverage Active Directory experience to manage and maintain our critical infrastructure. Use your PowerShell scripting skills to automate tasks, improve efficiency, and enhance the reliability of our AD environment. Play a key role in securing our Active Directory infrastructure, implementing and enforcing security best practices. Collaborate with development and infrastructure teams to design and implement solutions that improve the performance and scalability of our systems.

If you have: 3-12 year of AD experience A strong understanding of Active Directory concepts and technologies. Proven experience with PowerShell scripting for automation. A passion for security and a desire to learn and grow in this area. Excellent communication and collaboration skills. Then we encourage you to apply!

Due to an email's poor choice of words and a miscommunication, a mailbox was accidentally deleted. By me, on a night shift, who just woke up from a nap, sadly. I can go on with excuses, but I really deleted it instead of just suspending the user, like what we usually do. :(

We use Exchange Server 2013, no MS Office 365. The AD is on Server 2012 R2.

Edit:

Thank you for the responses! I was able to recover the mailbox thru EAC, and connecting it to an account w/o an existing mailbox. Thank you, sysads. Very much appreciated. ☺️

Hi everyone,

I've been tasked with updating our ridiculously old password policy.I know it´s shit. The current requirements are:

• Minimum 10 characters

• Must include numbers

• No password expiration

Currently, the password policy is configured in the Default Domain Policy. Before I just go "fire and forget" and change it, I’d rather play it safe and get some advice.

My main questions:

1. Should I remove the password policy from the Default Domain Policy and create a separate GPO for passwords? Or is it better to update the settings directly in the Default Domain Policy?

2. If I increase the minimum password length to 14 characters (whether in the Default Domain Policy or a separate GPO), will all users (approx. 500) immediately be forced to change their password if it is shorter than 14 characters? Or will they only need to change it when their current password expires?

3. Would it be better to use fine-grained password policies (FGPP) to apply different requirements for different user groups (admins, standard users, service accounts)? Or would that just add unnecessary administrative overhead?

Looking forward to your experiences and recommendations!

Thanks in advance!

EDIT Reddit Hug of death, I will migrate it tonight

Hello I wanted to share a script I made that will generate a high overview HTML report on your Active Directory environment. Since the report is in HTML you can interact with you data by searching your data tables, change header sorting and more.

The script needs the ActiveDirectory module as well as ReportHTML but it will attempt to install the ReportHTML module if it cannot find it.

Features

Interactive Pie Charts: The Pie Charts will show you the value, and the count of what you are hovering over.

Search: In the top right corner of the tables you can search the table for items. In my example I just want to see all results with “Brad” and filter everything that does not match that out.

Header Ordering: By clicking on a different header I can change the sorting of the data. In my example I changed the data to order it by “Enabled” status, then “Protected from Deletion” and finally “Name”.