Web Application Proxy Server in 2012 R2

When Microsoft discontinued Threat Management Gateway (which once was Proxy and then ISA server) I must admit I was disappointed; it was a relatively inexpensive authenticated reverse proxy that worked with Exchange Server as well as many other complicated products. In the interim we were told that Unified Access Gateway would be the replacement, but that product isn't as well suited to the task.

Several alternatives are out there, including: Kemp, F5, Nginx, and Squid but either the price or the relative difficulty of setup isn't in line with TMG. Fortunately starting in Windows 2012R2 Microsoft introduced Web Application Proxy which largely fills the gap.

Web Application Proxy/Server 2012r2 release party.Trust me, I paid big bucks for this insider photo.

What is Web Application Proxy?

Web Application Proxy (WAP from henceforth) is based on and replaces Active Directory Federation Services Proxy 2.0. In addition to the ADFS Proxy functionality it also introduces the ability to expose internal resources to external users. These users can be pre-authenticated (and then impersonated for SSO) against your Active Directory infrastructure using ADFS prior to being allowed access to resources. 

Wait, This is ADFS Proxy 3.0?

Yup! That and more. Here's what you can do with it:

• Authorize external users for access to other claims-aware external or internal resources (Generally SaaS).
• Allow access (by "reverse" proxy) to multiple internal applications on the same port.
• Pre-Authenticate users against Active Directory via Kerberos or NTLM to facilitate SSO and access to internal applications (if desired)
• Expose multiple internal resources on a single IP address/port (generally 443) differentiated by hostname
• Loadbalance using a session affinity based solution in front of WAP

Let's Go!

This article will cover the following:

• WAP requirements
• Set up
• Forwarding a couple of sample applications
• Troubleshooting

Software Requirements

Web application proxy is available on Windows Server 2012 R2 and higher, and it requires ADFS 3.0 to be available on the back end. For assistance in setting up ADFS 3.0, see my article here. If you would like to proxy authentication for non-claims aware applications, I.E. Exchange OWA pre-2013 SP1 (SP1 Claims) or Kerberos/NTLM apps, you will need to have the WAP server joined to your domain.

Additionally, you'll need the certificate (private and public key) from your ADFS server and one certificate (again, private and public) for each application you intend to proxy. These certificates must be trusted by your clients, so generally external globally trusted (Digicert for example) certificate authorities are preferred. The certificates need to be installed under the "Personal" portion of the "Local Machine" store on the machine you intend to use as your WAP proxy. If you only intend to host internal resources to domain-joined computers connecting remotely you can use an internal PKI provided your clients trust your issuing CA(s). For information on how to setup an internal CA, see my article here. If you need help exporting your public and private key from your ADFS server and other services, see this article. Note that if these certificates are marked as non-exportable you will need new certificates for those services, so make sure you plan accordingly.

Connectivity and Hardware/VM Requirements

Preferably, your WAP server should be placed in a De-Militarized Zone with a firewall on either side of it. The machine can operate with either one or two Network Interface Cards, but for proper security I recommend two NICs; one internal and one external. Other connectivity options will work, including branching into your internal network on the inside interface, but I won't be covering those scenarios in detail. For all connectivity options see the following diagram:

As for the hardware you can use either real hardware or a VM assuming you have a proper DMZ NIC setup on your Hyper-V/ESX/Xen/whatever host(s). WAP is not a particularly demanding application and uses very little I/O. It is also horizontally scalable with a network level load balancer (f5) so I won't give direct guidance on specifications since it would likely have little relevance to your configuration. As in most cases, performance evaluation and configuration change is the way to go.

After deciding on your hardware and installing the OS, you'll need to configure the NICs. We'll cover that in the next section...

Installation

Now that the hardware and OS are ready to go, let's configure the NICs:

Network Configuration

1. First open the "Network and Sharing Center" and click "Change Adapter Settings". Re-name the NICs "External" and "Internal" according to how they are connected to avoid confusion during set up and troubleshooting.
   
   
   
   
   
2. Give each NIC appropriate IP address settings. The subnet for each will depend on your firewall/switch configuration. Some firewall configurations may require communication stay on a single subnet but if given a choice it is generally better to have them on different subnets. (2 NICs) Leave the default gateway on the internal NIC blank. If your WAP server is not domain joined because you intend on using only claims auth or passthrough (not delegation) then leave your DNS servers blank on the internal NIC as well and be sure to execute step 4.
3. If the WAP server needs to access resources (ADFS, DC, App) on a subnet other than that the internal NIC is connected to, you will need to add a static route to the server so it knows how to get to that network. For example, if your WAP server is on 192.168.1.10/24, your ADFS server is 192.168.2.5/24, and your gateway is 192.168.1.1, you would issue the following command from an elevated command prompt: route ADD 192.168.2.0 MASK 255.255.255.0 192.168.1.1 IF 192.168.1.10 -p . For more information, see this article.
4. <Only if you haven't specified DNS servers on the internal NIC>To look up the ADFS server for claims verification you will need to add each internal ADFS server address to your %SYSTEMROOT%\system32\drivers\etc\hosts file. Do this now; if you need further instructions see this article.
5. Now we'll secure the external NIC. Open the properties of that NIC and on the "Networking" tab unbind everything except for "QoS Packet Scheduler" and the protocol you intend on using (IPv4 or IPv6).
6. If using IPv4, drill into the properties of that protocol and select "Disable NetBIOS over TCP/IP" under the "WINS" tab. Also ensure you disable "Register this connection's address in DNS" on the "DNS" tab.
   
   
   
   
   
7. On your external firewall, open the ports for the services you wish to forward. (443 would be common)
8. On your internal firewall, open ports necessary for AD/other communication. Here is an excellent guide.

WAP Installation

1. In server manager, click "Manage->Add Roles and Features".
2. Click "Next" on the "Before you begin" screen.
3. For "Installation Type" select "Role-based or feature-based installation" & click "Next".
   
   
   
   
   
4. Select your desired WAP server and click "Next".
5. On "Add Roles and Features Wizard", select the "Remote Access" role and click "Next".
   
   
   


6. You do not need to select any features; click "Next" on the "Select features" page.
7. Read the dialog presented on the "Remote Access" screen and click "Next".
8. Leave "Include management tools" checked and click "Add Features".
   
   
   
   
   
9. On the "Select role services" page select "Web Application Proxy" and click "Next".
   
   
   
   
   
10. When presented with the confirmation screen, click "Install".
    

WAP Configuration

Prerequisite Note: For this step you will need the public and private key for your internal ADFS server(s) installed to the "Personal" section of the "Local Computer" store on your WAP server. For more information, refer to "Software Requirements" above.

1. After installation, server manager will notify you that configuration is required. Click the notification flag and select "Open the Web Application Proxy Wizard".
   
   
   
   
   
2. On the "Welcome" screen of the "Web Application Proxy Wizard" click "Next".
3. On the "Federation Server" screen, enter the external fully qualified domain name of your federation service. This needs to be registered in external DNS (i.e. resolvable from the internet).  For more information, see my article linked under "Software Requirements". Insert the username/password of a domain administrator account to properly register this as a proxy server. This account will not be used after this point, so a service account is not necessary. Click "Next".
   
   
   
   
   
4. Select the ADFS certificate you installed earlier from the dropdown and click "Next".
   
   
   
   
   
5. You'll be presented with the configuration details. If you intend on setting up another WAP server for load balancing copy the powershell command down for later use. Click "Configure" to continue.
   
   
   
   
   
6. You should see the message "Web Application Proxy was configured successfully".
   
   
   
   
   

Setup Verification

To verify basic functionality:

1. On the WAP server, open up Tools->Remote Access Management Console
2. On the left-hand navigation pane, select "Operations Status"
3. The status of the WAP server will be relayed in the middle pane. Do not be surprised to see the server listed twice, once for the FQDN and once for netbios. This is normal. 

Now that setup is complete, let's move on to publishing!

Example A: Proxying Exchange 2010 OWA (Pre-auth/Non-Claims/Delegated Authentication)

Now that we've completed the ADFS/WAP setup, let's walk through the setup of a non-claims aware application using Kerberos/NTLM delegation. A popular example would be Exchange Outlook Web Access; I'll be using version 2010 SP3.

Prerequisite Note: For this step you will need the public and private key for the services you wish to host (Exchange OWA in this case) installed to the "Personal" section of the "Local Computer" store on your WAP server. Requests destined for your back-end service are decrypted and re-encrypted at the WAP server. For more information, refer to "Software Requirements" above.

Trust Setup

First, we must set up the new trust on the ADFS server. On your back-end ADFS server (not the WAP server) do the following: 

1. Open the AD FS management tool and click the "Trust Relationships" folder on the left hand navigation pane. 
2. In the right hand action pane, click "Add Non-Claims-Aware Relaying Party Trust".
   
   
   
   
   
3. A wizard will pop up; click "Start" on the welcome screen.
   
   
   
   
   
4. Give this rule a (human) meaningful name, i.e." <Servername> Exchange OWA" along with a description if desired and click "Next".
   
   
   
   
   
5. Now we'll add the non-claims aware relaying trust party identifier (which in this case is simply a URL). Enter the external fully qualified domain name of the server complete with url path ending in a trailing forward slash, i.e. https://mail.company.com/owa/ and click "Next". Note: WAP identifiers must end in a trailing slash even though the MSFT example doesn't look that way.
   
   
   
   
   
6. On the next screen, "Configure Multi-Factor Authentication Now?", you can set up multi-factor authentication should you desire. I will not be configuring multi-factor for this demonstration, but note you can always set it up later if desired. Leave "I do not want to configure..." selected and click "Next".
   
   
   
   
   
7. Review your configuration on the "Ready to Add Trust" screen and click "Next".
8. The "Finish" screen will have a checkbox starting with "Open the Edit Authorization Rules dialog..." that is checked by default. Leave it checked because we will want to specify who is allowed access through to the back-end via this rule right away. Click "Finish".
   
   
   
   
   
9. A dialog box titled "Edit Claim Rules for <Rule Name>" will come up allowing us to define who should be allowed access via this rule. Click "Add Rule'.
   
   
   
   
   
10. You will be asked to select a rule template. What you select here will depend on what is reasonable for your environment. You should create (a) rule(s) that correspond with the least access required possible as anyone getting past this point will be able to attempt to authenticate directly against the target internal resource. You may, for example, want to use a specific Active Directory group with only the users that need access to this resources. For the purposes of testing and this article, however, I will be using a simple "Permit All Users" rule. This will allow anyone in AD through and is suitable for testing or in addition to other rules. Select the rule template and click "Next".
    
    
    
    
    
11. Click "Finish" to close the "Add Issuance Authorization Claim Rule Wizard"
12. So long as you do not want any additional rules, click "OK" to close the Edit Claim Rules dialog box.
    
    
    
    
    

Back-end Service Configuration

Now we need to configure our back-end service to accept the authentication coming from the WAP server. In our case we will need to change the  authentication mechanism allowed by Exchange from forms based to integrated authentication.Your steps here will differ depending on what service you are offering up.

1. Open the Exchange management console and Click on "Server Configuration"->"Client Access"
2. For each server in your Exchange farm, click the "Outlook Web App" tab, then right click "owa (Default Web Site)" and click "properties".
   
   
   
   
   
3. Select the "Authentication" tab and click "Use one or more standard authentication methods:" then select only "Integrated Windows authentication".
   
   
   
   
   
4. Click "OK" on the warning.
5. Repeat steps 2 and 3 for the "ecp (Default Web Site)" under "Exchange Control Panel" on each server. 
6. Using an elevated command prompt or PowerShell, execute "iisreset -noforce" to restart IIS. (This should be done in a maintenance window)

Configure Delegation

Now we'll configure the WAP server AD computer object so that it can pass authentication to your back-end server(s). Note the SPNs referenced to not need to be manually registered at a domain level.

1. With domain administrator privileges, open the Active Directory Administrative Center. (Active Directory Users and Computers if you prefer)
2. Navigate to and open the properties of the WAP server computer object.
   
   
   
   
   
3. Click or scroll down to the "Delegation" section of the object.
   
   
   
   
   
4. Select "Trust this computer for delegation to specified servers only" and "Use any authentication protocol" (since we'll be using NTLM here; select Kerberos only for applications that support it) then click "Add..."
5. When presented with the "Add Services" dialog, click "Add Users or Computers...".
   
   
   
   
   
6. Type the name of the back-end Exchange server(s) and click "Check Names" and then "OK"
7. Scroll to the http/SERVERNAME.domain.ext (since we're serving up the HTTP protocol; change if your app differs) and select it, then click "OK". Note: If using Active Directory Administrative Center you need to add the FQDN name and the NETBIOS name; if using Active Directory Users Computers you need only add the FQDN and both will be added.
   
   
   
   
   

Configure Application Publishing on WAP Server

Finally we'll configure WAP publishing for this application.

1. On the WAP server, open the Remote Access Management Console (can be found in admin tools or tools from Server Manager)
2. In the left hand navigation plane, select "Configuration"->"Web Application Proxy"
3. On the right hand action pane, click "Publish"
   
   
   
   
   
4. A wizard will come up. Click "Next" on the welcome screen.
5. When prompted for preauthentication type, select "Active Directory Federation Services (AD FS)". This ensures requests are authenticated by ADFS prior to being passed onto the back-end server. Click "Next".
   
   
   
   
   
6. For "Relying Party", select the trust rule we created earlier under the "Trust Setup" section above and click "Next".
   
   
   
    
   
7. Now the meat of the settings; on the "Publishing Settings" step enter a meaningful name for this connection (i.e. Exchange 2010 OWA), the external URL it will be accessed by (i.e. https://mail.company.com/owa/), select the external certificate for that service (see "Software Requirements" above), the internal URL (preferably should match the external but doesn't have to in all cases), and the server SPN that we specified on the step above, then click "Next".
   
   
   
   
   
8. You will be shown the confirmation screen with the appropriate PowerShell command line for the options you have configured. Should you want to repeat a similar publishing step, copy and retain this command line for use later. Click "Publish".
   
   
   
   
   
9. The results screen will display the publishing status. Assuming all is well, click "Close" to close the wizard.

Example B: RDP Proxy (No Pre-auth/Passthrough)

Passthrough applications are substantially easier (and less secure) because they do not require any set up in ADFS and do not subject the user connection attempt to any authentication before passing it on. This isn't to say the back-end service won't require authentication, however, but it is still less secure since you are opening your back-end service up to processing logon requests directly from the internet. 

Publish RDP Proxy on WAP Server

In this example I will publish RDP proxy direct to the internet proxied through the WAP server. This allows me to serve up this application on the same IP address and port as other services assuming the hostname requested is unique. Again, this section assumes the public and private keys associated with the URL you intend to use installed in the WAP server's "personal" store. In my example I use a hostname of "rdp.company.com"

1. On the WAP server, open the Remote Access Management Console (can be found in admin tools or tools from Server Manager)
2. In the left hand navigation plane, select "Configuration"->"Web Application Proxy"
3. On the right hand action pane, click "Publish"
4. A wizard will come up. Click "Next" on the welcome screen.
5. When prompted for preauthentication type, select "Pass-through" and click "Next".
   
   
   
   
   
6. On the "Publishing Settings" step enter a meaningful name for this connection (i.e. RDProxy), the external URL it will be accessed by (i.e. https://rdp.company.com/), select the external certificate for that service (see "Software Requirements" above), and the internal URL (preferably should match the external but doesn't have to in all cases). Click "Next".
   
   
   
   
   
7. You will be given a summary of the publishing rule about to be created and a Powershell command of it's equivalent. If you are satisfied with the details click "Publish".

Troubleshooting

Something not working? Check out the following locations:

Event Logs

Applications and Services Logs->AD FS/Admin
Applications and Services Logs->Microsoft->Windows->WebApplicationProxy/Admin

Other

Should you need to enable debug logging, there is an excellent article here demonstrating how to do so. One word of caution, however; should you edit the C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config referenced therein I recommend backing it up first. If not formatted correctly WAP will start up successfully with the values listed in the file, but when it comes time to rotate the ADFS Proxy Trust certificate (an automatic action that happens once every 3 weeks) the configuration of the new cert will fail. In that case you would see an Event ID 422 logged to AD FS/Admin stating "Unable to retrieve proxy configuration data from the Federation Service.".

(Excellent!) References

Want more? Here are some wonderful resources!

Technet: Web Application Proxy Overview
Technet: Install and Configure the Web Application Proxy Server
Technet: Installing and Configuring Web Application Proxy for Publishing Internal Applications
Technet Overview Guide: Connect to Applications and Services from Anywhere with Web Application Proxy
Technet Social: On WAP and IPv6
Technet Social: ADFS, WAP, and Logging
Technet Blog: How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2 (Needed to support Android clients for Exchange ActiveSync or other clients that don't support SNI hosted through WAP)
Technet Ask PFE: FAQ on ADFS Part 1, Excellent coverage of SQL vs. Internal DB and certificates for AD FS (Not WAP per se)
Marc Terblanche: Windows 2012 R2 Preview Web Application Proxy - Exchange 2013 Publishing Tests
Ask the DS Team: Understanding the ADFS 2.0 Proxy (Not about WAP but excellent coverage of AD FS proxy functionality)
Rob Sanders: Troubleshooting ADFS 2.0 (Not about 3.0/WAP but too good not to be mentioned)
Technet: Configure Event Logging on a Federation Server Proxy (Still partially relevant)
Technet: Things to check before troubleshooting ADFS 2.0 (Still partially relevant)
Technet: Configuring Computers for Troubleshooting AD FS 2.0 (Still partially relevant)

Thanks for reading, if you have questions or comments leave them below!

Monitoring Windows: Granular Service Rights in an Enterprise Environment

Foreword

I'm a big fan of Splunk and similar tools for network and systems monitoring. This new generation of machine data analysis brings a myriad of product and monitoring opportunities. These systems work by indexing large swaths of machine logging (logs, performance information, etc.) and providing an incredibly effective interface for reporting of that information.To achieve this, however, you need to provide very broad access to target systems.

If for any reason you can't use Universal Forwarders on Windows platforms, data collection can be difficult. While Splunk provides some great documentation, it suffers from the same access (and granting) problem as other platforms needing similar access. Generally this problem is solved in one of two ways:

• Grant local administrator access on every machine to be monitored to a single service account. Clearly this won't fly in organizations concerned with granting the least amount of access needed for their application portfolio. A single service account/group that has administrator everywhere is a significant security risk. 
• Use Group Policy to grant rights, ACLs, etc. The problem with this approach is that some things cannot be addressed by GPO (WMI) and if granting user rights often you cannot be granular enough since each right defined must list all accounts/groups that get that right. Across an enterprise that is a difficult and potentially costly proposition. The main problem with setting user rights via Group Policy is that the rights are not additive; they overwrite all entries including required system or other application entries. This makes central management of thousands of machines impractical. Say you need to define "act as part of the operating system" for your monitoring software; you would then need to centrally define every account/group that has that right and any machine that needs to define that right in a different way would need to obtain an override GPO for the machines in question. While this is possible, many very large organizations find it difficult to execute.

Neither one of these solutions is desirable in a medium to large sized enterprise due to security requirements and management complexities. To address this issue in a more granular way than the two options listed above, we can use scripts to automate local configuration where necessary.

I'll be using Powershell scripts to perform the following tasks:

• Add Active Directory groups/users to local groups
• Grant WMI rights to Active Directory groups/users
• Grant local user rights to  Active Directory groups/users

Assuming the affected security principals are not set elsewhere, we can set these items with scripts that can be triggered via group policy. I'll be using the GPO startup script functionality, but you can feel free to use any other trigger mechanism you prefer (logon script, etc.). Note that this solution will work for products similar to Splunk that require similar rights.

Execution

First things first, we need to establish what we'll be doing and principals to which we want to grant access.

Assumptions

• Splunk indexer (or your other monitoring tool) installed and ready to go
• You have administrative rights on all machines in question and Active Directory rights sufficient to create the service account/group(s)
• You would rather use the Splunk Indexer to collect information rather than install the Splunk Universal Installer on your target machines (Good option as well). 
• Powershell 2.0 or newer & Windows 2003 or newer. This could be done with batch/executables or VBScript but I won't be covering that.

Service Account/Group Setup

Per the Splunk instructions, create a service account to run Splunk. This will require administrative access on the machine running Splunk, but nothing else (yet). It would be best to use a managed service account but if you cannot a standard account will be fine.

Splunk instructions deem that an Active Directory group need be created to contain the service account. This isn't really necessary, but there are potential advantages so we'll stick to it.

After creating/configuring that service account, create the service account group and make your service account a member. For the purposes of our demonstration I've named this group "Splunk Accounts"

You should monitor this group to ensure no other accounts are added since doing so would grant those accounts unwanted rights.

Now let's configure services. The service account will need to be local administrator on machines running the Splunk software (splunkd, splunkweb) directly (more on this another time). After granting local admin, stop the Splunkd and splunkweb services, change the logon to your new service account and start them back up.

Now let's tackle the interesting part: granting granular rights to the service account group.

Objective 

Our objective is to grant the appropriate rights to the service account group on every machine in our enterprise that we wish to monitor. Per the documentation from Splunk, the minimum rights to collect Event Log and WMI data remotely on a Windows platform are: 

Misc

• WMI rights under root/cimv2
• DCOM launch permissions

User Rights

• Access this Computer from the Network
• Act as part of the operating system (I'd like to confirm this one; not sure why)
• Log on as a batch job
• Log on as a service
• Profile System Performance
• Replace a process level token (not sure about this one either)

Local Group Membership

• Distributed COM Users
• Event Log Readers
• Performance Log Users

I'm sure you can see the why the official documentation prefers local admin rights. :)  Fortunately, we've got automation to do our heavy lifting.

Scripts

Let's examine the scripts we'll be using. I've prepared four scripts for this task: 

• Powershell script to grant WMI and DCOM rights (Grant-WMIACL.ps1)
• Powershell script to grant User Rights (Grant-Rights.ps1)
• Powershell script to add local group membership and tie the others together (Setup-Splunkuser.ps1)
• Batch file to launch powershell script correctly on all platforms (SetupSplunkuser.bat)

Grant-WMIACL.ps1

As discussed, this script will grant the appropriate WMI and DCOM access. This is based heavily on the work of Steve Lee and Karl Mitschke. Note that I've left options in the script and commented out to change the level of access given to the WMI objects, including the ability to toggle inheritance. I've left these in to help you decipher the SDDL structure. That said, the line that is not commented out in this will work fine for our application. This script could be run remotely (hence the $strComputer="localhost" line) but we'll be using it locally (more on that below).

Grant-WMIACL.ps1 (Click to Expand)  + 

if ($args[0] -eq $null)
{
 Write-Warning "No account or group name provided as an argument. Re-launch with the principal to grant rights to as the first argument."
 Throw "I don't know what to do, please specify username, i.e. mydomain\myuser"
}
$Uname=$args[0]

Write-Warning "Granting WMI and DCOM access to $Uname..."

#This function gets a SID from an account name
function get-sid
{
 Param ($DSIdentity)
 $ID = new-object System.Security.Principal.NTAccount($DSIdentity)
 return $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString()
}
$sid = get-sid $Uname

#Enable Account, Remote Enable
#maps to "CC"  SDDL_CREATE_CHILD  ADS_RIGHT_DS_CREATE_CHILD , "WP"  SDDL_WRITE_PROPERTY  ADS_RIGHT_DS_WRITE_PROP 
#$SDDL = "A;;CCWP;;;$sid"

#Provider Write(RP), Enable Account, Remote Enable
#maps to "RP"  SDDL_READ_PROPERTY  ADS_RIGHT_DS_READ_PROP , "CC"  SDDL_CREATE_CHILD  ADS_RIGHT_DS_CREATE_CHILD , "WP"  SDDL_WRITE_PROPERTY  ADS_RIGHT_DS_WRITE_PROP 
#$SDDL = "A;;CCWPRP;;;$sid"

#Execute Methods(DC), Provider Write(RP), Enable Account, Remote Enable
#maps to "DC"  SDDL_DELETE_CHILD  ADS_RIGHT_DS_DELETE_CHILD , "RP"  SDDL_READ_PROPERTY  ADS_RIGHT_DS_READ_PROP , "CC"  SDDL_CREATE_CHILD  ADS_RIGHT_DS_CREATE_CHILD , "WP"  SDDL_WRITE_PROPERTY  ADS_RIGHT_DS_WRITE_PROP 
#$SDDL = "A;;CCWPRPDC;;;$sid"

#Execute Methods(DC), Provider Write(RP), Enable Account, Remote Enable WITH INHERITENCE!! (note CI is in the header) 
#maps to "CI"  SDDL_CONTAINER_INHERIT  CONTAINER_INHERIT_ACE , "DC"  SDDL_DELETE_CHILD  ADS_RIGHT_DS_DELETE_CHILD , "RP"  SDDL_READ_PROPERTY  ADS_RIGHT_DS_READ_PROP , "CC"  SDDL_CREATE_CHILD  ADS_RIGHT_DS_CREATE_CHILD , "WP"  SDDL_WRITE_PROPERTY  ADS_RIGHT_DS_WRITE_PROP 
$SDDL = "A;CI;CCWPRPDC;;;$sid"

#Local Launch and Remote Activation
$DCOMSDDL = "A;;CCDCRP;;;$sid"

#Local Launch, Local Activation, Remote Launch, remote Activation
#$DCOMSDDL = “A;;CCDCLCSWRP;;;$sid”

#$computers = Get-Content "computers.txt"
#foreach ($strcomputer in $computers)
#{
$strComputer="localhost"
$Reg = [WMIClass]"\\$strComputer\root\default:StdRegProv"
$DCOM = $Reg.GetBinaryValue(2147483650,"software\microsoft\ole","MachineLaunchRestriction").uValue
$security = Get-WmiObject -ComputerName $strcomputer -Namespace root/cimv2 -Class __SystemSecurity
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$binarySD = @($null)
$result = $security.PsBase.InvokeMethod("GetSD",$binarySD)
$outsddl = $converter.BinarySDToSDDL($binarySD[0])
$outDCOMSDDL = $converter.BinarySDToSDDL($DCOM)
$newSDDL = $outsddl.SDDL += "(" + $SDDL + ")"
$newDCOMSDDL = $outDCOMSDDL.SDDL += "(" + $DCOMSDDL + ")"
$WMIbinarySD = $converter.SDDLToBinarySD($newSDDL)
$WMIconvertedPermissions = ,$WMIbinarySD.BinarySD
$DCOMbinarySD = $converter.SDDLToBinarySD($newDCOMSDDL)
$DCOMconvertedPermissions = ,$DCOMbinarySD.BinarySD
#Set WMI Permissions
$result = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
#Set DCOM Permissions
$result = $Reg.SetBinaryValue(2147483650,"software\microsoft\ole","MachineLaunchRestriction", $DCOMbinarySD.binarySD)

She's a beaut eh? Now for Grant-Rights.ps1:

This one is huge because we're using full .NET code in the beginning. That code is a combination of snippets from here, here, and here. Note the comments displaying the short names for some of the rights we can assign which I've left in to facilitate applying this approach to systems other than Spunk. More can be found here.

Grant-Rights.ps1 (Click to Expand)  + 

Add-Type @'
using System;
using System.Collections.Generic;
using System.Text;

namespace MyLsaWrapper
{
    using System.Runtime.InteropServices;
    using System.Security;
    using System.Management;
    using System.Runtime.CompilerServices;
    using System.ComponentModel;

    using LSA_HANDLE = IntPtr;

    [StructLayout(LayoutKind.Sequential)]
    struct LSA_OBJECT_ATTRIBUTES
    {
        internal int Length;
        internal IntPtr RootDirectory;
        internal IntPtr ObjectName;
        internal int Attributes;
        internal IntPtr SecurityDescriptor;
        internal IntPtr SecurityQualityOfService;
    }
    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    struct LSA_UNICODE_STRING
    {
        internal ushort Length;
        internal ushort MaximumLength;
        [MarshalAs(UnmanagedType.LPWStr)]
        internal string Buffer;
    }
    sealed class Win32Sec
    {
        [DllImport("advapi32", CharSet = CharSet.Unicode, SetLastError = true),
        SuppressUnmanagedCodeSecurityAttribute]
        internal static extern uint LsaOpenPolicy(
        LSA_UNICODE_STRING[] SystemName,
        ref LSA_OBJECT_ATTRIBUTES ObjectAttributes,
        int AccessMask,
        out IntPtr PolicyHandle
        );

        [DllImport("advapi32", CharSet = CharSet.Unicode, SetLastError = true),
        SuppressUnmanagedCodeSecurityAttribute]
        internal static extern uint LsaAddAccountRights(
        LSA_HANDLE PolicyHandle,
        IntPtr pSID,
        LSA_UNICODE_STRING[] UserRights,
        int CountOfRights
        );

        [DllImport("advapi32", CharSet = CharSet.Unicode, SetLastError = true),
        SuppressUnmanagedCodeSecurityAttribute]
        internal static extern int LsaLookupNames2(
        LSA_HANDLE PolicyHandle,
        uint Flags,
        uint Count,
        LSA_UNICODE_STRING[] Names,
        ref IntPtr ReferencedDomains,
        ref IntPtr Sids
        );

        [DllImport("advapi32")]
        internal static extern int LsaNtStatusToWinError(int NTSTATUS);

        [DllImport("advapi32")]
        internal static extern int LsaClose(IntPtr PolicyHandle);

        [DllImport("advapi32")]
        internal static extern int LsaFreeMemory(IntPtr Buffer);

    }
    /// 

    /// This class is used to grant "Log on as a service", "Log on as a batchjob", "Log on localy" etc.
    /// to a user.
    /// 
    public sealed class LsaWrapper : IDisposable
    {
        [StructLayout(LayoutKind.Sequential)]
        struct LSA_TRUST_INFORMATION
        {
            internal LSA_UNICODE_STRING Name;
            internal IntPtr Sid;
        }
        [StructLayout(LayoutKind.Sequential)]
        struct LSA_TRANSLATED_SID2
        {
            internal SidNameUse Use;
            internal IntPtr Sid;
            internal int DomainIndex;
            uint Flags;
        }

        [StructLayout(LayoutKind.Sequential)]
        struct LSA_REFERENCED_DOMAIN_LIST
        {
            internal uint Entries;
            internal LSA_TRUST_INFORMATION Domains;
        }

        enum SidNameUse : int
        {
            User = 1,
            Group = 2,
            Domain = 3,
            Alias = 4,
            KnownGroup = 5,
            DeletedAccount = 6,
            Invalid = 7,
            Unknown = 8,
            Computer = 9
        }

        enum Access : int
        {
            POLICY_READ = 0x20006,
            POLICY_ALL_ACCESS = 0x00F0FFF,
            POLICY_EXECUTE = 0X20801,
            POLICY_WRITE = 0X207F8
        }
        const uint STATUS_ACCESS_DENIED = 0xc0000022;
        const uint STATUS_INSUFFICIENT_RESOURCES = 0xc000009a;
        const uint STATUS_NO_MEMORY = 0xc0000017;

        IntPtr lsaHandle;

        public LsaWrapper()
            : this(null)
        { }
        // // local system if systemName is null
        public LsaWrapper(string systemName)
        {
            LSA_OBJECT_ATTRIBUTES lsaAttr;
            lsaAttr.RootDirectory = IntPtr.Zero;
            lsaAttr.ObjectName = IntPtr.Zero;
            lsaAttr.Attributes = 0;
            lsaAttr.SecurityDescriptor = IntPtr.Zero;
            lsaAttr.SecurityQualityOfService = IntPtr.Zero;
            lsaAttr.Length = Marshal.SizeOf(typeof(LSA_OBJECT_ATTRIBUTES));
            lsaHandle = IntPtr.Zero;
            LSA_UNICODE_STRING[] system = null;
            if (systemName != null)
            {
                system = new LSA_UNICODE_STRING[1];
                system[0] = InitLsaString(systemName);
            }

            uint ret = Win32Sec.LsaOpenPolicy(system, ref lsaAttr,
            (int)Access.POLICY_ALL_ACCESS, out lsaHandle);
            if (ret == 0)
                return;
            if (ret == STATUS_ACCESS_DENIED)
            {
                throw new UnauthorizedAccessException();
            }
            if ((ret == STATUS_INSUFFICIENT_RESOURCES) || (ret == STATUS_NO_MEMORY))
            {
                throw new OutOfMemoryException();
            }
            throw new Win32Exception(Win32Sec.LsaNtStatusToWinError((int)ret));
        }

        public void AddPrivileges(string account, string privilege)
        {
            LSA_UNICODE_STRING[] names = new LSA_UNICODE_STRING[1];
            LSA_TRANSLATED_SID2 lts;
            IntPtr tsids = IntPtr.Zero;
            IntPtr tdom = IntPtr.Zero;
            names[0] = InitLsaString(account);
            lts.Sid = IntPtr.Zero;
            Console.WriteLine("String account: {0}", names[0].Length);
            int ret1 = Win32Sec.LsaLookupNames2(lsaHandle, 0, 1, names, ref tdom, ref tsids);
            if (ret1 != 0)
                throw new Win32Exception(Win32Sec.LsaNtStatusToWinError(ret1));
            lts = (LSA_TRANSLATED_SID2)Marshal.PtrToStructure(tsids, typeof(LSA_TRANSLATED_SID2));
            IntPtr pSid = lts.Sid;
            //IntPtr pSid = GetSIDInformation(account);
            LSA_UNICODE_STRING[] privileges = new LSA_UNICODE_STRING[1];
            privileges[0] = InitLsaString(privilege);
            uint ret = Win32Sec.LsaAddAccountRights(lsaHandle, pSid, privileges, 1);
            Win32Sec.LsaFreeMemory(tsids);
            Win32Sec.LsaFreeMemory(tdom);
            if (ret == 0)
                return;
            if (ret == STATUS_ACCESS_DENIED)
            {
                throw new UnauthorizedAccessException();
            }
            if ((ret == STATUS_INSUFFICIENT_RESOURCES) || (ret == STATUS_NO_MEMORY))
            {
                throw new OutOfMemoryException();
            }
            throw new Win32Exception(Win32Sec.LsaNtStatusToWinError((int)ret));
        }

        public void Dispose()
        {
            if (lsaHandle != IntPtr.Zero)
            {
                Win32Sec.LsaClose(lsaHandle);
                lsaHandle = IntPtr.Zero;
            }
            GC.SuppressFinalize(this);
        }
        ~LsaWrapper()
        {
            Dispose();
        }
        // helper functions

        IntPtr GetSIDInformation(string account)
        {
            LSA_UNICODE_STRING[] names = new LSA_UNICODE_STRING[1];
            LSA_TRANSLATED_SID2 lts;
            IntPtr tsids = IntPtr.Zero;
            IntPtr tdom = IntPtr.Zero;
            names[0] = InitLsaString(account);
            lts.Sid = IntPtr.Zero;
            Console.WriteLine("String account: {0}", names[0].Length);
            int ret = Win32Sec.LsaLookupNames2(lsaHandle, 0, 1, names, ref tdom, ref tsids);
            if (ret != 0)
                throw new Win32Exception(Win32Sec.LsaNtStatusToWinError(ret));
            lts = (LSA_TRANSLATED_SID2)Marshal.PtrToStructure(tsids,
            typeof(LSA_TRANSLATED_SID2));
            Win32Sec.LsaFreeMemory(tsids);
            Win32Sec.LsaFreeMemory(tdom);
            return lts.Sid;
        }

        static LSA_UNICODE_STRING InitLsaString(string s)
        {
            // Unicode strings max. 32KB
            if (s.Length > 0x7ffe)
                throw new ArgumentException("String too long");
            LSA_UNICODE_STRING lus = new LSA_UNICODE_STRING();
            lus.Buffer = s;
            lus.Length = (ushort)(s.Length * sizeof(char));
            lus.MaximumLength = (ushort)(lus.Length + sizeof(char));
            return lus;
        }
    }
    public class LsaWrapperCaller
    {
        public static void AddPrivileges(string account, string privilege)
        {
            using (LsaWrapper lsaWrapper = new LsaWrapper())
            {
                lsaWrapper.AddPrivileges(account, privilege);
            }
        }
    }
}

'@


#Access this Computer from the Network
#SeNetworkLogonRight
#
#Act as part of the operating system
#SeTcbPrivilege
#
#Log on as a batch job
#SeBatchLogonRight
#
#Log on as a service
#SeServiceLogonRight
#
#Profile System Performance
#SeSystemProfilePrivilege
#
#Replace a process level token
#SeAssignPrimaryTokenPrivilege

if ($args[0] -eq $null -or $args[1] -eq $null)
{
 Write-Warning "Available privs:"
 Write-Host ""
 Write-Host "Access this Computer from the Network"
 Write-Warning "SeNetworkLogonRight"
 Write-Host ""
 Write-Host "Act as part of the operating system"
 Write-Warning "SeTcbPrivilege"
 Write-Host ""
 Write-Host "Log on as a batch job"
 Write-Warning "SeBatchLogonRight"
 Write-Host ""
 Write-Host "Log on as a service"
 Write-Warning "SeServiceLogonRight"
 Write-Host ""
 Write-Host "Profile System Performance"
 Write-Warning "SeSystemProfilePrivilege"
 Write-Host ""
 Write-Host "Replace a process level token"
 Write-Warning "SeAssignPrimaryTokenPrivilege"
 Throw "I don't know what to do, please specify username,right, i.e. mydomain\myuser, SeServiceLogonRight"
}

$Uname=$args[0]
$Right=$args[1]

Write-Warning "Giving $Right to $Uname..."
[MyLsaWrapper.LsaWrapperCaller]::AddPrivileges($Uname, $Right)

Don't let the length of that code scare you off; the only part you need to understand is the last few lines. Now let's examine Setup-Splunkuser.ps1:

This script does a few things: defines the target for these privileges, adds those to a series of groups, and ties the other scripts together. The one thing you'll definitely want to modify is the entry at the top, $SplunkAcct="MYDOMAIN\Splunk Accounts". This should be the domain and group you created to host the service account(s). The next line, $localGroups="Distributed COM Users","Event Log Readers","Performance Log Users" local groups to which you want to add AD groups to, each in quotes and separated by commas. What I've set it to here is perfect for Splunk, but feel free to change it for your needs.

Setup-Splunkuser.ps1 (Click to Expand)  + 

$SplunkAcct="MYDOMAIN\Splunk Accounts"
$localGroups="Distributed COM Users","Event Log Readers","Performance Log Users"

#Get-ScriptDirectory Function #
#############################################################

function Get-ScriptDirectory
{
$Invocation = (Get-Variable MyInvocation -Scope 1).Value
$path=Split-Path $Invocation.MyCommand.Path
# INSERT ESCAPE CHARACTERS FOR USING PATHS IN COMMANDS
$path=$path.replace('{','`{')
$path=$path.replace('}','`}')
$path=$path.replace('[','`[')
$path=$path.replace(']','`]')
$path

}
#**********************************************************************************************************************

#get directory
$ScriptDir=Get-ScriptDirectory

#grant rights
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeNetworkLogonRight'"
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeTcbPrivilege'"
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeBatchLogonRight'"
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeServiceLogonRight'"
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeSystemProfilePrivilege'"
Invoke-Expression "$scriptdir\Grant-Rights.ps1 '$SplunkAcct' 'SeAssignPrimaryTokenPrivilege'"

#grant WMI ACLs
Invoke-Expression "$scriptdir\Grant-WMIACL.ps1 '$SplunkAcct'"

#add local group access

#NOTE WE ARE CHANGING THE ACCT VARIABLE TO A FORWARDSLASH NOW DO ALL OTHER FUNCTIONS BEFORE THIS

$SplunkAcct=$SplunkAcct.replace('\','/')
foreach ($localGroup in $localGroups)
{
 $lclGrp=[ADSI]"WinNT://$env:COMPUTERNAME/$localGroup,group"
 $lclGrp.psbase.Invoke("Add",([ADSI]"WinNT://$SplunkAcct").path)
}

Now for the final piece to the puzzle: SetupSplunkuser.bat:

This script exists to provide compatibility with 2008 (not R2) and lower. Native Powershell scripts run correctly on 2008R2 and higher, but a batch launched script will run from 2003 up with no problem. This will be the script we'll use to kick everything off.

powershell.exe -nologo -noexit -file %~dp0\Setup-SplunkUser.ps1

Now that we have our scripts in place, we need to do the hard part. Run them everywhere we would like in the enterprise.

Running the Scripts on Target Machines

As discussed earlier, there are several ways to accomplish this. The solution I'll be using is Group Policy by utilizing the Startup Script functionality in the Computer portion of the policy. Setting up the group policy is easy, the difficult part is getting the scripts to run correctly, but we'll worry about that when we get there. 

Determine Your Target Machines

If you want to configure Splunk access rights across all machines in your domain you can plan on using the default domain policy GPO to roll out these changes. If you're reading this article, however, I suspect you want to be more targeted with your application of changes.

I recommend using security filtering against the desired groups of computers. If you don't already have groups you would like to use, create a security group in Active Directory and add your desired machines to it. To do this on a large scale, you can use something like this.

After you have your target group(s) set up, you need to configure the group policy you plan on using to execute the script. If this GPO doesn't yet exist, create it and apply the security filtering listed above. Edit the GPO using GPMC:

1. After opening the GPO, navigate to "Computer Configuration->Policies->Windows Settings->Scripts (Startup/Shutdown)





2. Select "Startup". 
3. Click "Show Files..."; this will open a folder on your sysvol volume associated with this Group Policy Object. 





4. After modifying accordingly (Setup-Splunkuser.ps1) copy all four scripts into the folder. These will be automatically replicated to all domain controllers in the domain. 





5. Back on the "Startup Properties" screen, ensure the "Scripts" tab is selected (not Powershell Scripts) and click "Add". 
6. Type or browse to SetupSplunkUser.bat. And click "OK" twice. 

This now is triggered to run on reboot for all impacted machines, but we're not done yet. We still have to navigate the oddly challenging world of running Powershell scripts in the Windows environment.

Running Powershell Scripts in a Distributed Environment - The Problem

The hurdle using this solution is a larger problem: By default, Powershell scripts are super scary and won't run in your environment for two reasons:

• By default, running scripts requires those scripts be signed. 
• By default, scripts will not run from the "internet", and for some reason the UNC path to the domain controller that may have just authenticated you is considered the "internet" by Windows. 

More here. There are two ways to solve this problem. 

• Secure Way/PKI(Recommended): If you have an internal PKI you can sign all your scripts AND add the signer cert(s) to the trusted publisher store on all targeted machines in Active Directory. 
• Not-So Secure Way/Disable Security: You can run scripts from your DC by setting the execution policy in Powershell to "Unrestricted" and adding your domain controller sysvol share to the trusted sites zone in Internet Explorer configuration. 

I will briefly discuss each solution. 

Secure Solution - PKI

This is the preferred and most secure method. While you could do this with certificates from a public authority, it is recommended that you use your own Active Directory integrated PKI for this. Here is a very high-level overview of the steps:

1. Acquire a code signer cert from your PKI. If using a Windows PKI you can use the "Code Signing" template, but it really should be customized first. Export or save the public key (.cer) because we'll need it later. 
2. Sign each script with the following code (substituting scriptname.ps1 with the location of your script): 

#This assumes you have only one code signing script
#use Get-Childitem cert:\CurrentUser\My -codesigning to see all and change index if necessary

$cert=@(Get-Childitem cert:\CurrentUser\My -codesigning)[0]

#Do this for each script and change scriptname.ps1 to the actual script name

Set-AuthenticodeSignature .\scriptname.ps1 $cert

3. Copy the scripts into the sysvol share as outlined above. 
4. Edit the GPO you would like to use to distribute the script... the same one you're using to run the scripts above would be the perfect match. 
5. Navigate to "Computer Configuration->Policies->Windows Settings->Security Settings->Public Key Policies->Trusted Publishers"
6. Right click->Import and select your public key (.cer) corresponding to your code signing cert. 

Close the GPO and you should now be good. Once the certificate propagates to the target machines they'll run the signed scripts without issue. 

Alternative Solution A - Disable Security for this Script

1. Edit the SetupSplunkUser.bat script and change the line to:

powershell.exe -ExecutionPolicy Bypass -nologo -noexit -file %~dp0\Setup-SplunkUser.ps1

2. Upload the file to your sysvol share as described above. 
3. If you have issues running the other Powershell scripts that are called from the first, you may have to use some trickery: such as this.

Alternative Solution B - Disable Security Permanently

1. Edit the GPO you would like to use to distribute the script... the same one you're using to run the scripts would be the perfect match. 
2. Navigate to "Computer Configuration->Policies->Administrative Templates->Windows Components->Windows Powershell"
3. Edit "Turn on Script Execution" and change it to "Enabled" and "Allow all scripts". Click OK and close the GPO. 
4. Add your domain sysvol path (ensure you use your domain name, not your domain controller name) to the trusted sites zone: see here and here. OR change the UACAsInternet property; see here. 

That should do it! Remote eventlog, WMI, and most other types of remote collection should now work using Splunk.

Troubleshooting

If you have issues getting or determining if the scripts are running successfully, try the following:

• Try executing SetupSplunkUser.bat from an elevated command prompt on one of the target machines. Note any issues. 
• To audit running in a test group, you can add a line like "ran script Setup-SplunkUser.ps1" | Out-File "c:\temp\temp.txt" to create a log of the script execution on each machine. 
• Script execution should be logged in the Application Log of each server. 

With this information you should be able to better control the service rights of Splunk or similar software in a large enterprise environment and still keep your auditors happy. For an added bonus, you could use Splunk itself for security auditing now that your're done.