PowerShell: XML Object Save Method

The .Save() method of an [xml] object appears to default to "C:\Windows" instead of the current working directory. 

PS C:\Users\thepip3r\Desktop\Scripts>[xml]$xml = gc .\myxml.xml

PS C:\Users\thepip3r\Desktop\Scripts>$xml.Save("newxml.xml")

Throws an access-denied error (for my normal user account) about the inability to save the file to "C:\Windows" because Access is Denied.

On another note, you can pass a path with the filename and the Save method will save it to the specified location.

PowerShell: Copy an XML object

This is going to sound incredibly simple and stupid to some but I had a problem when I started working with XML ([xml]) objects in PowerShell regarding the creation of duplicates and/or copying of XML objects.

My scenario was that I was reading in an XML config file for Microsoft NAP, altering some values for different sites/domains, and then outputting a modified version of the XML that was specific for each site/domain that could then be imported to keep the configs identical between each site/domain.  My problem is that I was taking my local NAP server and using those values as the expected values so I didn't want it to change with each iteration of the domain/site so I thought to create a "temp" copy after reading the XML file in:

$xml = gc .\myxmlfile.xml

$sites | ForEach-Object {

   $xml2 = $xml

   ...

}

...For normal PowerShell objects, this would work fine to create a duplicate object and assign it to $xml2.  For some reason that is beyond me, this doesn't work for XML objects.  What it does is create a reference to the original object.  So if you modify the XML in $xml2 using the assignment method above, you will actually be modifying $xml. 

What I ended up discovering is that if you do a Get-Member on an [xml] object, you'll see a method called Clone().  The proper assignment in my loop that resolved this issue was:

$xml2 = $xml.Clone()

PowerShell: Useful Active Directory .NET Methods

  

[Active Directory Forest]:

• Name:
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Name
• Application Partitions: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ApplicationPartitions
• Sites: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites
• Global Catalogs:  
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs
• Domains: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Domains
• Functional Level: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ForestMode  
• Root Domain: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().RootDomain
• Schema DN/Role: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Schema
• FSMO - Schema Master: 
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().SchemaRoleOwner
• FSMO - Domain Naming Master:  
• [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().NamingRoleOwner

[Active Directory Domain]:

 * If you need this information from the computer's domain you're running this on, switch out GetCurrentDomain() for GetComputerDomain() and all of these will work as well.

• FSMO - Infrastructure Master:  
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().InfrastructureRoleOwner
• FSMO - PDC Emulator: 
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().PdcRoleOwner
• FSMO - RID Master: 
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().RidRoleOwner
• Domain Controllers: 
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers
• Functional Level: 
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainMode
• Domain Parent:
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Parent
• Functional Level:
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainMode
• Child Domains:
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Children
• Forest:
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Forest
• Name:
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

[Computer Specific]:

• Site: 
• [System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()
• User Domain: 
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name
• Computer Domain:  
• [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Name

PowerShell - Reorder/Rename CDROM/DVDROM devices in reverse alphabetical order

Title:  Reorder CDROM/DVDROM Drive Letters in Reverse Alpha
Description:

If you reorder your CDROM/DVDROM drives in reverse alphabetical order in your environment, you may have use for this script.  If you have one or more "disk drives" on a system, you can run this script and it will reorder them in reverse alphabetical order. 

Example:

1. If you have a single drive on a single system, if you run this script, it will be relablelled as the "Z:" drive.
2. If you have multiple drives on a single system (e.g. E:, F:, G:), they will be relabelled as Z:, Y:, X:, respectively.

Known Issues/Limitations:

1. Does not account for drives already in use.
2. Does not account for the potential of a large number of disk drives that would be greater than 26.

Script:

$CDROMs = @(Get-WmiObject Win32_Volume -Filter "DriveType=5")
    
$Alpha = @()
65..90 | % { $Alpha += [char]$_ }
    
for ($x=0; $x -lt $CDROMs.Count; $x++) {
    $idx = 25 - $x
        
    $CDROMs[$x] | Set-WmiInstance -Arguments @{DriveLetter = "$($Alpha[$idx])`:" }
} 

DNS Views/BIND Views on Windows DNS?

In order to understand why BIND administrators want this functionality, we'll spend some time explaining what BIND Views offer, what Windows offers, and how they differ.  Then we'll look at an example to try and help bring it all together.
What is DNS Views/BIND Views?

BIND Views is a feature of BIND that allows you to create records with a configuration such that, when the name server responds to a lookup, it will return the IP address of the host relative to the configuration of the "view".  To be more specific, you can make BIND provide network-specific IP address answers based off of the requester's IP address.

Why would you want to do this?

Let's say you have a web farm across a global enterprise and you have a corporate web portal that is rather complex.  Instead of simply pointing everyone to http://www.randomcorpname.com/, you decide that you want to use a moniker like "my.randomcorpname.com".  This "my" moniker configured as a "view" in BIND can default to the Hong Kong web farm and specific portion of the portal for it's Hong Kong users, the San Francisco portion of the portal and web farm for the San Francisco users, and London portion of the portal and web farm for the London users -- simply by users at each location typing in the same value:  "my.randomcorpname.com."

Can you perform this same action in Windows DNS?

The answer is a mixed-bag of yes and no:

1. Is the robustness of BIND Views identical in Windows?  No.  
2. Is it even close?  No.
3. Can I perform similar, network-centric DNS answers using Windows DNS?  Yes -- Windows actually does this by default on Windows 2003 DNS servers and beyond but for it to work properly, your network has to be IP'd in such a way to support it or Windows DNS will simply default to round-robining.

How can I implement network-centric answers similar to BIND Views in Windows?

The short answer is Windows netmask ordering. 

How do BIND Views and Windows netmask ordering differ?

In BIND Views, you can create View records that define network-by-network who will recieve what IP address as an answer.  The configuration of the networks can be any number of network addresses across any number of different classes of network (A,B,C, etc.)

In Windows netmask ordering, the DNS server gets configured to "look" at a particular set of bits on the network mask of the requestor, and then provide the appropriate A-record relative the class configuration of the DNS server and there being an A-record for the hostname with that same "class-value" of the requester existing in DNS.  By default, Windows DNS defaults to a "Class-C"-style matching.

Let's look at an example:

We'll shift our example using BIND above to the internal enclave since Windows netmask ordering would be so painful to manage in the same fashion as described above and because I'd never have a Windows DNS server on a non-internal boundary of my network.  So in our shifted example, we are a sprawling company with offices all over the world.  We have a portal website where we want people being directed to specific servers/farms based off of their location in the world but each location have the ability to use the same moniker to access the intranet portal:  intranet.randomcorpname.local.

Hostname/A-Record, IP Address
hk-web01.randomcorpname.local., 10.0.1.11
hk-web02.randomcorpname.local., 10.0.1.12
sf-web01.randomcorpname.local., 10.1.1.11
sf-web02.randomcorpname.local., 10.1.1.12
lon-web01.randomcorpname.local., 10.2.1.11
lon-web02.randomcorpname.local., 10.2.1.12

Additional A-Records for Netmask Ordering
intranet, 10.0.1.11
intranet, 10.0.1.12
intranet, 10.1.1.11
intranet, 10.1.1.12
intranet, 10.2.1.11
intranet, 10.2.1.12

In this example and in most medium-to-large networks, the default configuration for netmask ordering in Windows DNS will not work for proximity-based resolution because you typically segregate clients/workstations by subnet.  Any machines that are NOT on the same /24 as the web server, will ignore netmask ordering and proceed to just round-robin.  In our example with the current IP configuration, you would need to adjust the netmask ordering mask from the default Class-C to a Class-B (or something in between) in order to make this work.

If we were to adjust the netmask ordering mask of our DNS servers to a Class B (0x0000ffff), then our Windows DNS server would properly respond as desired.  In our example with our Windows DNS server configured with a netmask ordering mask set to 0x0000ffff, then a client in Hong Kong (let's say, 10.0.2.10) who does a lookup on "intranet" will properly round-robin between 10.0.1.11 and 10.0.1.12.  Similarly, a client with address 10.2.2.10 (London), will appropriately round-robin between 10.2.1.11 and 10.2.1.12.

Notice that we've changed the comparison of the third octet (Class-C) to the second octet (Class-B).  Also notice how static this configuration is and how dependent it is upon a very strict and consistent IP addressing scheme.

Relevant Command-Line Utilities/Commands to Netmask Ordering:

1. dnscmd /Info /LocalNetPriorityNetmask
2. dnscmd /Config /LocalNetPriorityNetmask 0x0000ffff

If you run the command in item number 1, you should get back:  "Dword:  255 (000000FF)" -- this is the default configuration.  Also notice that if you do a 'dnscmd /Info /?', the /LocalNetPriorityNetmask parameter is not documented.  I don't know if this means Microsoft is deprecating this functionality or just that it's hidden for some reason.

References:

1. http://support.microsoft.com/kb/842197
2. http://technet.microsoft.com/en-us/library/cc940789.aspx

RDP Assistant v1.0

Program Name:     RDP Assistant

Program Version:  v1.0

Language:              PowerShell v2.0

Description:

This tool was developed for people who need to RDP frequently in their jobs.  The tool is nothing more than a quick way to execute multiple RDP windows simultaneously.  You can add computers individually by hostname and domain or by using an Active Directory distinguishedName value to an OU/Container that has computer objects in it.

RDPAssistant.ps1



Example: 

You need to update all domain controllers in all domains you manage [assumes you have all servers loaded in the list]:

1. Use your system naming nomenclature to filter the list of servers to only domain controllers (e.g. "dc").
2. Select all objects.
3. Hit, "Go".

This will open RDP windows to all of the selected hosts.

Windows Web Security: Why you DON'T run IIS AppPools with user accounts that have elevated rights to a domain.

Title:  Windows Web Security:  Why you DON'T run IIS AppPools with user accounts that have elevated rights to a domain.

Description:  Windows AppPool account passwords are exposable as clear-text to a local Administrator of an IIS server.

Vulnerability:  If your IIS machine is compromised and an AppPool running on that machine is running with a domain account that has elevated user rights, the attacker simply needs to run a PowerShell command to see the username and password of an account with domain credentials.  This also applies in an administratively segregrated environment where you have an Administrator of an IIS server who should not have domain-level rights.

Requirements:  at least IIS 7/Windows 2008 R2 if not before.  I haven't tested this on previous versions but should still be testable via the root\MicrosoftIISv2 namespace.

Proof of Concept:

You can see the AppPool Name as well as the configured domain username and password.  This was run using a local Administrator account on an IIS server.