This week was quite productive. We downloaded the Powershell scripts I wrote for work so we could begin implementing some test-cases using both Powershell and the MMC console. The first problems we ran into were ExecutionPolicy issues – we resolved these by modifying the default execution policy for the IT\ElevatedPrivs OU and running Powershell as an administrator. We had to use net use commands to remap the networked home drives in the elevated instance. This allowed us to run the scripts from our test users’ home drives.
First, we decided to terminate some users with my ADTerminate script. This script disables an account, sets the description to “Termed mm/dd/yyy” and wipes out all group memberships. This let us test that our help-desk and systems administration users had the right authority for access removals. We followed up by using the console to create new users. In addition, we successfully added and removed users from individual groups using both the MMC console and Powershell scripts. We also tested the ADCopyGroups script which essentially copies all group memberships from one user to another user.
As part of the ongoing server hardening process, we needed to implement a higher password length for users with elevated priviledges. The IT OU was linked to a new group policy object which increased the minimum password length from 8 characters to 16 characters. The MMC console iterator tops out at 14, so in order to get 16 we had to go in and manually edit the policy via the file system. We found the path of the new group policy via the policy ID and edited a line within the file.
\\$DOMAIN\SYSVOL\$DOMAIN\Policies\$PolicyGUID\Machine\Microsoft\Windows NT\SecEdit
Following the increased password requirements, we wanted to test by expiring the passwords of an IT user and a non-IT user to demonstrate and confirm that we linked the GPO correctly. We decided to do this via a Powershell command. After expiring a user’s password, we verified the user’s password is actually expired by loading their information via my ADInfo script. After that, we logged in as those users to check if the new password requirements were being enforced. Successful results were achieved.
Set-ADUser $username -ChangePasswordAtLogon:$true
Ultimately, we wanted to confirm that our IT personnel had all of the accesses they would need to run the company. We verified that help-desk cannot access the Cumulus server and that they do not have the ability to modify users within the IT domain. Only the SysAdmin users have the capability to modify any of the IT users – we confirmed this as well using both Powershell and MMC console. Interns are also not granted any permissions within Active Directory Users and Computers and have read-only access to the domain.
We then began testing on the base-level users such as the sales department and call center employees. Each sales employee has different shared folder accesses which we need to make sure they had access to. As it turns out, most of them hadn’t been added to the appropriate security groups for access to their respective sales departments. We set it up with a number of sales employees having different combinations for testing various configurations and levels of access.
Making sure these lower-level users were also restricted from certain systems was a priority as well. Although corporate sales employees were the lowest on the totem in the main office, they got the standard corporate level accesses. This meant no administrative privileges but retaining accesses such as limited control panel, start menu and other quality-of-life features. The idea is that as corporate employees they’ll need a certain amount of OS customization to let them optimize their workflow.
On the other hand, our call center employees needed to be on an almost absolute lock-down. They have a very specific workflow which does not need that kind of flexibility. We ensured that our test call center user Vicki Nolan had the heavily restricted access such as a locked-down start menu, no control panel, and no control panel.
All in all, I feel that our testing this week was successful. We even managed to find a couple oversights with regards to file share accesses. While we did do some limited checking of users as we were setting them up, doing some dedicated testing now ensures that nothing was broken or that we missed anything. Overall, I’d call this week a success.
