Archive for the ‘Windows Server 2008’ Category

Powershell Script to Locate Windows Services Running as Domain users

Ever had to change a domain administrator’s password and had the sinking feeling that some bozo had setup a Windows service to run as that user.   If you only have a couple servers it isn’t that big a deal to check each manually, but if you have a lot it can be a problem.  I’ve seen a lot of admins just use the scream test to figure out what broke, but sometimes it isn’t obvious until the server is rebooted.  We run into this situation frequently as we take over new clients.

Recently we had to make a change for a customer with 50+ Windows servers and I knew the account had been used for services. I just didn’t know where.  So I built the below powershell script.  I definitely owe a few people props as I used a number of different websites to figure out the WMI piece. Unfortunately, it has been too long since I remember who.  But the next best thing is to put this script out there for other to use.  So I have posted the script and a readme file to GitHub (a new experience for me, but way better than how I published my scripts previously).

Hope this helps out.  This is provided “as-is” and while I’ve used in several environments I can’t guarantee it will work everywhere.  Feel free to leave respectful comments.


Set Owner with PowerShell: “The security identifier is not allowed to be the owner of this object”

I’ve written several PowerShell scripts to help customers adjust permissions to their directory structures when migrating from other file servers(Linux/Samba, Novell OES/Netware, etc).  Part of these scripts includes assigning ownership for the user.  While this tends to take a long time quotas and file reporting are worthless if the administrator that copied everything is assigned as the owner.

Recently I tried to adapt one of these scripts for a customer, but when I ran it it failed with the error: “The security identifier is not allowed to be the owner of this object”

A quick internet search found lots of people saying basically this can’t be done with PowerShell.  What!!! I know for a fact these scripts had worked before.  What’s the deal?   After a lot of testing and beating my head against the wall I figure out I was trying to do something different.  Previously I had run my scripts against the UNC path (eg. \\servername\share\directory), but this time I was trying to run it on a local directory using the drive path (E:\Share\Directory).

Could it be that simple? Yes.  I ran the command again using the UNC path and the script worked as it did before.

Here is an example script to set the owner of a directory or file to test the above:

function pathPrompt {

$tempPath = $null
$tempPath = Read-Host ‘Please enter the path of thedirectory (e.g. “\\file\vol1\users\example”‘
return $tempPath

$ID = new-object System.Security.Principal.NTAccount($domain, $username)

$path = pathPrompt

write-host $path

$acl = get-acl $path
set-acl -path $path -aclObject $acl

Save the above to a file with a .PS1 extension, change the $username and $domain variables, and run it (make sure you set-executionpolicy to unrestricted and PowerShell as administrator). It will prompt for a path. It will then write the path to powershell and then set the owner if it can.

Below is an example of running it against a local path and a UNC path.

Disabling RDP Network Level Authentication (NLA) remotely via the registry

So I logged into a server that was setup by another administrator using RDP to configure some software.  For whatever reason it is requesting a reboot, so I let it reboot before I start my work.  After the server comes back up I attempt to connect and get a “The connection cannot continue because the identity of the remote computer cannot be verified” error.

From experience I knew this means that Network Level Authentication (NLA) is enabled.  NLA is a nice security feature if you have an internal Certificate Authority and time to configure auto-enrollment, but most smaller organization opt for the “less secure” option.  Since I have no console level access I’d have to wait for an onsite technician to change it to allow for “less secure” connectivity.

But I can remote into another server on the same local network and connect to the registry.  A quick google search failed to identify the key/value to change so I did some digging and testing and found it.

To disable NLA remotely:

  1.  Open regedit on another computer on the same network.
  2. Under the File menu click “Connect Network Registry…”
  3. Enter your computer name and click Ok.  If this fails to connect you may be out of luck.
  4. Scroll down in the left pane to find the newly added server. Navigate to this Key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
  5. Find the value “SecurityLayer” and change the data to 0  (that is a zero).
  6. Voila, I was able to remote in without issue.

Creating Lists of Installed Applications

Frequently while performing network assessments I need to assemble a list of all the programs installed on servers. Going to Add/Remove Programs and writing it down is a tedious process.  Installing applications like Belarc Advisor is a bit more intrusive then I want to be on another companies servers.  After some research today I found two solutions that work well:

For XP and Server 2003

The above contains the contents of a vbscript. You copy the contents into a text file and save it with a .vbs extension.  You can then double-click it. It will prompt you for a computer name or IP address. When it finishes running it generates a file that contains a list of all the programs installed.  It seems to work great with Windows XP and 2003, but only returns a partial list for Windows 2008. 

 For Vista, Windows 7, Server 2008 and 2008 R2

This link shows how to generate the list using wmi commands. It says it is for vista and windows 7, but seems to work on Server 2008 just fine. Unlike the vbscript, this must be run directly on the computer in question.


Both these methods seem to work well, but they do generate files on the system that need to be copied off to be useful.  If you are using them on someone elses computers I would advise you get explicit permission before using these tool. 

Unrelated but also helpful.

If your assessment involves Dell servers, you might want to get the service tags for the servers.  Older Dells tend to put this sticker in inconvenient locations. Luckily you can query the servers for the tag using this handy vbscript.

Using Windows Server 2008 as a RADIUS Server for a Cisco ASA

Recently I needed to get a Cisco ASA 5510 to use a RADIUS Server on Server 2008 to authenticate Active Directory users for VPN access. The ASA was already configured to use a Server 2003 RADIUS server, so much of the below was just replicating the existing configuration on a 2008 server. I suspect many of the settings are less than ideal and some are unnecessary, but the below steps worked for now.


  • AD1:
    • Windows Server 2008
    • Also the domain controller
    • IP:
  • CiscoASA:
    • ASA 5510 (though I believe these instructions should work for all ASA models)
    • IP:

Cisco Configuration

I performed the Cisco configuration using the ASDM management tool. The same configuration could be achieved via the command line interface, but I found the ASDM was more convenient for checking existing settings and then replicating.

Launch ASDM and connecting to the ASA, I went to the Configuration view.

Create an IP Name object for the target

  1. Under the Firewall section, expand the Objects link and select the IP Names.
  2. Click the Add button at the top.
  3. Enter a descriptive name, the IP address and a description of the server. For this server I used
  4. Name: INT-AD1
  5. IP:
  6. Description: AD / RADIUS
  7. Click OK and then Apply

Create a new AAA Server Group

  1. Click the Remote Access VPN section.
  2. Expand AAA Setup and select AAA Server Groups.
  3. Click the Add button to the right of the AAA Server Groups section.
  4. Give the server group a name, like TEST-AD, and make sure the RADIUS protocol is selected.
  5. Accept the default for the other settings. And click OK

Add the RADIUS server to the Server Group.

  1. Select the server group created in the step above.
  2. Click the Add button to the right of Servers in the Select Group.
  3. Under the Interface Name select the interface on the ASA that will have access to the RADIUS server, most likely inside.
  4. Under Server Name or IP Address enter the IP Name you created for the RADIUS server above.
  5. Skip to the Server Secret Key field and create a complex password. Make sure you document this as it is required when configuring the RADIUS server. Re-enter the secret in the Common Password field.
  6. Leave the rest of the settings at the defaults and click Ok.

Setting Up RADIUS on Windows Server 2008

This part gave me the most trouble. The documentation from Microsoft was somewhat vague and other resources I found using the trusty Google method listed steps and addition pieces I knew to be unnecessary.

To perform the below steps you need Administrator permissions to the server that will host the RADIUS server. You also will need permissions to “Register” the server in AD. I believe this requires Domain Admin privileges.

Add the Network Policy Server function.

  1. Connect to the Windows Server 2008 server and launch Server Manager.
  2. Click the Roles object and then click the Add Roles link on the right.
  3. Click Next on the Before You Begin page.
  4. Select the Network Policy and Access Services role and click Next.
  5. Under Role Service select only the Network Policy Server service and click Next.
  6. Click Install.


After the role finishes installing you will need to set up the server using the Network Policy Server (NPS) management tool found under Administrative Tools.

Registering the server.

  1. After launching the NPS tool right-click on the entry NPS(Local) and click the Register Server in Active Directory.
  2. Follow the default prompts.

Create a RADIUS client entry for the ASA.

  1. Expand the RADIUS Clients and Servers folder.
  2. Right-click on RADIUS Clients and select New RADIUS Client.
  3. Create a Friendly Name for the ASA device. I used “CiscoASA” but if you had more than one you might want to make it more unique and identifiable. Make sure you document the Friendly Name used as it will be used later in some of the policies created.
  4. Enter the Server Secret Key specified on during the ASA configuration in the Shared secret and Confirm shared secret field.
  5. Leave the default values for the other settings and click OK. See Figure 1 for all the complete RADIUS Client properties.

Figure 1

Create a Connection Request Policy.

  1. Expand the Policies folder.
  2. Right-click on the Connection Request Policies and click New.
  3. Set the Policy Nameto something meaningful. I used CiscoASA because this policy is geared specifically for that RADIUS client. Leave the Type of network access server as Unspecified and click Next.
  4. Under Conditions click Add. Scroll down and select the Client Friendly Name condition and click Add…
  5. Specify the friendly name that you used when creating the RADIUS Client above. Click OK and Next.
  6. On the next two pages leave the default settings and click Next.
  7. Under the Specify a Realm Name select the Attribute option on the left. From the drop down menu next to Attribute: on the right select User-Name. Click Next again.
  8. Review the settings on the next page and click Finish.

Create a Network Policy.

  1. Right-click the Network Policy folder and click New.
  2. Set the Policy Name to something meaningful. Leave the Type of network access server as Unspecified and click Next.
  3. Under Conditions click Add.
  4. Add a UsersGroup condition to limit access to a specific AD user group. You can use a generic group like Domain Users or create a group specifically to restrict access.
  5. Add a Client Friendly Name condition and again specify the Friendly Name you used for your RADIUS client.
  6. Click Next. Leave Access granted selected and click Next again.
  7. (Important Step) On the authentication methods leave the default selection and add Unencrypted authentication (PAP, SPAP).
  8. Accept the default Constraints and click Next.
  9. Accept the default Radius Settings and click Next. Review the settings and click Finish.

Restart the Network Policy Server service.

  • This may not be necessary, but I did this at various points and cannot be certain the above steps work without restarting the service.

Test Your RADIUS Authentication

The ASDM utility includes functionality to test RADIUS Authentication.

  1. If necessary re-launch the ASDM utility.
  2. Return to Configuration -> Remote Access VPN -> AAA Setup -> AAA Server Groups.
  3. Select the new Server Group you created.
  4. From the Servers in the Selected Group section highlight the server you created. Click the Test button on the right.
  5. Select the Authentication radio button. Enter the Username and Password of a user that meets the conditions specified in the Network Policy created above then click OK.
  6. If everything works as designed you should see something similar to:

Save your Cisco Configuration

Don’t forget to save the running configuration to memory on your ASA. Otherwise you’ll lose all your settings the next time the device is rebooted.