A Domain Controller is not a Domain Computer – Online memory of an Active Directory PFE
— Read on blogs.technet.microsoft.com/389thoughts/2018/12/10/a-domain-controller-is-not-a-domain-computer/
Another Forensics Blog: When Windows Lies
— Read on az4n6.blogspot.com/2017/02/when-windows-lies.html
A large majority of breaches happen because of compromised credentials (https://blog.centrify.com/cause-of-data-breaches/) and so it stands to reason that a compromise of privileged credentials would be the worst case scenario. If someone gets hold of Domain Admin credentials the game is essentially over.
Because of this when I’m talking to customers about improving their security posture one of the first things I recommend is reducing the number of accounts in AD privileged groups such as Domain Admin, Enterprise Admin and Schema Admins as documented in the Best Practices for Active Directory Security. What I often see is;
Lots of accounts in Domain Admins
IT administrators are often in Domain Admins. Sometimes, but not always, this account is separate from their day to day ‘normal’ account.
Service accounts in Domain Admins
I often ask why so many accounts are put in these groups and the answer is usually along the lines of;
‘I need those permissions’ or ‘stuff just works when an account is in that group’.
For me one of the simplest things you can do to help reduce the attack surface of AD is to simply remove accounts from these privileged groups. Ideally the only account in there would be the built in Administrator (RID 500) account.
AD Security resources;
I’ll do another post soon on Group Policy settings to help secure and audit your AD and Windows environment.
To get the last Windows boot time using PowerShell V3 or later.
Get-CimInstance Win32_OperatingSystem | select lastbootuptime,csname
This will show you the lastbootuptime and computer name
I’m in the process of migrating data from an aging file server to a new shiny one. On the old server the NTFS permissions are all over the place so I really wanted to copy the data to the new server without the existing NTFS permissions and then apply new ACLs on the new server.
I decided on Robocopy to copy the data. The command line and switches I used are;
robocopy \OldFileServershare \NewFileServerNewShare /MIR /COPY:DATO /DCOPY:T /ZB /r:1 /w:1 /log:robo.log
/MIR mirrors the entire directory structure
/COPY:DATO copes the Data, Attributes, Timestamps, Owner information. The NTFS permissions are not copied. Using an S in the above would also copy the NTFS access control list.
/DCOPY:T – Copies directory timestamps
/ZB – Use restart mode and if access to a file/directory is denied use the backup option (e.g. copy with backup privileges)
/r:1 – Specifies the number of retries on a failed item
/w:1 – Specifies the wait time between retries
/log Outputs the result of the copy to a log file
Using the /log file means you don’t see anything happening in the cmd window whilst robocopy is working. I like to use which is available as part of the System Center 2012 R2 Configuration Manager Toolkit
CMTrace is a SCCM tool and really good for viewing log files in real time. Opening robo.log with CMtrace means I can watch what Robocopy do its work whilst it is being output to a log file for me to view later. This can be handy in case there were any failures or warnings.
To find the date when Windows was installed;
Open a cmd window
systeminfo | find /i “install date”
PS C:Windowssystem32> systeminfo | find /i “install date”
Original Install Date: 16/10/2015, 14:09:01