Using PowerShell we can get list of users created during a particular time frame, like in last 1 day, 30 days, etc. This may be helpful in AD audit or to track any security breach.
First, create a variable and store the date you want to go back.
Make sure you run the PowerShell as Admin, if you don’t you may get blank values for WhenCreated
$When = (Get-Date).AddDays(-30) # You can change number of days here as per your requirement.
Get-ADUser -Filter {WhenCreated -ge $when}
#IF you want to list particular properties, you can use below command.
Get-ADUser -Filter {WhenCreated -ge $when} -Properties * | FT Name, UserPrincipalName, WhenCreated
We can also get group membership of these users in same command output.
You see some issues when trying to connect your file shares and get “Access Denied” error, also see events 5827 and 5828 in Domain controller Event Logs.
In your storage logs you also see error – AUTH: Domain Controller error: NetLogon error 0xc0000022: – Filer’s security information differs from domain controller
The cause of this issue is a patch which was released in two pashes and Microsoft has added these event
August 11, 2020- Initial Deployment Phase
In August, Microsoft released the first phase of a two-phase fix to force secure RPC with Netlogon.
This will flag all the no-secure RPC endpoints and will generate a warning in your event logs on domain controllers.
EventID 5829 triggers whenever a vulnerable Netlogon secure channel connection is allowed
February 9, 2021 -Enforcement Phase
The second phase activates an enforcement mode. “The DCs will now be in enforcement mode regardless of the enforcement mode registry key. This requires all Windows and non-Windows devices to use secure RPC with Netlogon secure channel or explicitly allow the account by adding an exception for the non-compliant device.
EventID 5827 and EventID 5828 trigger if vulnerable Netlogon connections are denied.
For non-Windows devices acting as a DC, these events will be logged in the system event log when using vulnerable Netlogon secure channel connections. If one of these events is logged
Recommended – Work with the device manufacturer (OEM) or software vendor to get support for secure RPC with Netlogon secure channel
Vulnerable If a non-compliant DC cannot support secure RPC with Netlogon secure channel before the DCs are in enforcement mode, add the DC using the “Domain controller: Allow vulnerable Netlogon secure channel connections” group policy described below.
Allowing vulnerable connections from 3rd party devices.
Use the “Domain controller: Allow vulnerable Netlogon secure channel connections” group policy to add non-compliant accounts. This should only be considered a short-term remedy until non-compliant devices are addressed as described above. Note Allowing vulnerable connections from non-compliant devices might have unknown security impact and should be allowed with caution.
Create a security group(s) for accounts which will be allowed to use a vulnerable Netlogon secure channel.
In Group Policy, go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Search for “Domain controller: Allow vulnerable Netlogon secure channel connections”.
If the Administrator group or if any group not specifically created for use with this Group Policy is present, remove it.
Add a security group specifically made for use with this Group Policy to the security descriptor with the “Allow” permission. Note The “Deny” permission behaves the same way as if the account was not added, i.e. the accounts will not be allowed to make vulnerable Netlogon secure channels.
Once the security group(s) is added, the group policy must replicate to every DC.
Periodically, monitor events 5827, 5828 and 5829 to determine which accounts are using vulnerable secure channel connections.
Add those machine accounts to the security group(s) as needed. Best practice Use security groups in the group policy and add accounts to the group so that membership is replicated through normal AD replication. This avoids frequent group policy updates and replication delays.
We can track the changes in AD accounts if the “User Account Management” Audit policy is enabled in Active Directory.
We can edit Default domain controller policy and under “Audit User Account Management” select both “Success” and “Failure”.
OR create a separate GPO and link to all the servers or workstation OU where we want to audit the account management.
The policy setting is under –
Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Account Management -> “Audit User Account Management” and select both “Success” and “Failure”.
Once the policy is configured, we will have below events generated under Security logs on AD Server for AD accounts and local server/workstation for local users.
Event ID 4720 – A user account was created.
Event ID 4722 – A user account was enabled.
Event ID 4723 – An attempt was made to change an account’s password.
Event ID 4724 – An attempt was made to reset an accounts password.
Event ID 4740 – A user account was locked out.
Event ID 4725 – A user account was disabled.
Event ID 4726 – A user account was deleted.
Event ID 4738 – A user account was changed.
Event ID 4781 – The name of an account was changed.
Now, to find the changes on any account, we can use AD replication log to find the time and DC name where change occurred.
Let’s suppose, I want to track the change on SAMAccountName for my test account.
You will find the DC Name and time where the SAM name changed.
Account lockout is one of the most common issues reported to a System Admin, the frequent account lockouts are annoying to users and hence for AD Admin also.
The most common cause for account lockout is when user changes the password and a stale session with cached old password keeps hitting the account.
There may be some bad actors also, like someone is trying to brute-force the password, or an SMTP/IMAP session is trying to authenticate.
In all cases we need to find out the device or session which may be sending bad password requests.
Using the below PowerShell command you can find out the Account Lockout and LastBadPassword Request.
You can also see Event 4776 (Audit Failure) in Security Logs of domain controller for bad password hit. IF the error code is C000006A, this means User name is correct but the password is wrong.
Once account is lockout, you will see Event 4740 in AD security logs.
Once you have this info, let’s find the source of bad password.
Replace AD-PDC-Server = Your PDC FSMO role holder and UserSAM = SAM of account you want to find lockout.
In the “Last Bad Pwd” column you will get the exact date/time and DC Name for last bad password hit.
Now, you can login that exact DC and find the event at exact time for source computer.
IF there is Exchange servers in Source Computer field, then you will have to parse the IIS Logs from your CAS server, check the exact date/time of badpassword/lockout and find the IIS logs on your Exchange CAS server.
If you see the Source Computer bank, you will have to start NETLOGON logs to find the source computer.
#Find Lockout source using PowerShell, #AD Account Lockout tool
I got an opportunity to Read and Review of book “Microsoft Exchange Server 2013 High Availability – Nuno Mota”. I just finished reading this book and here is my review about this book.
I highly recommend this book for the Admin(s) who have at least basic understating of Exchange 2013 and want to gain more In-depth knowledge about High-Availability of Exchange server in all respects. The book contains only about 200 pages and 8 chapter with really hands-on practical stuff, so you will not get bored while reading this book.
The book covers availability of all the server roles so you can design a highly available messaging environment. A quick snapshot about the changes introduced in high availability of Exchange 2013 provide a good platform for a reader to refresh and will benefit the reader in building the foundation.
And configure the helper address [for this creates a security group in AD and map you support person IDs on that group] and give the UNC path of that group.
Configure the policy “Solicited remote assistance”
The policy will be like this after this
Configuration from client end,
Check that the Windows remote assistance should be allowed from the local firewall allow list,
This is by default allowed.
On the client computer go to Start RUN – msra /offerra
The below dialog box will be open
Type the ip address/Hostname of the person which you want to connect
And click on next
The user will be prompted to accept the connection and
Now click on the share control and the user will be] prompted to accept the request.
After this you will be able to control the remote system.
