Automating best pratice for security groups in Active Directory

In order to maintain best practices in a multi domain forest, we occasionally have to create file and application access groups to secure sensitive resources we manage. Creating a 3 groups to do this is a lot of hassle, but it needs to be done, however you don’t need to do it manually.

I created a script to take care of this day to day task for me. The script basically does 3 thing:

  1. It checks if a security group with that name already exists and if so it aborts.
  2. It creates 3 security groups: a “Domain Local” group for rights assignment, a “Global” group to put my users in, and a “Universal” group to link the Global and Domain Local groups, as well as to link groups from other domains in our forest.
  3. It asks the user what folder to add rights to and what rights to add (Read, Write and/or Modify) and then sets those rights on the appropriate folder.

The script uses Quest Active Roles AD Management snapin for Powershell (available here)

I’ve added logging using the transcript functionality, and if you check out line 19 and 114 you see that I’m starting and stopping logging to a specific file using the “Start-Transcript” and “Stop-Transcript” cmdlets. This means that the script will throw and error in ISE since it doesn’t support transcripting, but running it in a normal powershell windows will ensure that everything happing between line 15 to 113 get’s logged!

Without further ado, heres the script:

 

I still consider myself a novice at Powershell, however and advanced one at that, and I’d love to get feedback on better approaches to my scripting, both in the sense of optimizing the script for performance, and simplifying the script itself. I’d also be happy to answer any questions regarding the script 🙂

Updating KMS server settings

I encountered a weird problem with our Key Management Server (KMS) and client licensing recently. The client I’m working with has 3 domains whereas there is a full two way trust between two of them, and limited trust towards the third.

For some reason our Vista client (yes, Vista) we’re trying to update the license towards a KMS service on a domain controller in the third domain with limited trust. It also seems KMS has been deactivated on this server, but that wasn’t the challenge.

To update the KMS server address you need to run the Visual Basic (VB) script c:windowssystem32slmgr.vbs. You can add argument to view the current configuration (-dli), manually set the KMS server (-skms) or do an autodiscover of the KMS server address (-ato).

In this case I ran the following command to see the current config:

I saw that the KMS server was not the one I expected for clients in this domain, so I ran this command to do an auto discover:

This generated an error:
Error code and message: 0xC004F039 The computer could not be activated. The Key Management Service could not be reached.

The cause for this error in our case was that the Vista client tried to update the license towards the last server it updated against. There is no error handling routine in slmgr.vbs that tells the client to do an auto discover of possible KMS servers elsewhere if it fails towards the server it last updated against.

To resolve this I had to clear the name of the KMS server the client already knew in order to force it to discover the actual KMS server on the intranet. I ran the following command to clear the name and run the auto discover:

 

NB. If this had failed, there would have been one last solution. You can update the name of the KMS server manually, thus bypassing the entire auto discovery and eliminating that as an error source. This requires you to know the name and port (usually port 1688) of the KMS server, and is done with the “-skms” switch like this: