Archive | Windows Admin

ADFS 2.0 in Forest Trust Environment

I’ve been meaning to get this out there for a while now.  I’m not going to go into great detail on ADFS but you can get more background on ADFS and federation in these posts:

Salesforce SSO with ADFS 2.0 – Everything You Need to Know

ADFS 2.0 Choose Your Attributes Wisely

SAML WebSSO Federation Made Easy

 

My scenario is as follows:

  • 2 domains in 2 forests with a one way trust between them.
    (For this post I’ll refer to these domains PERIMETER and INTERNAL)
  • PERIMETER trusts INTERNAL but INTERNAL doesn’t trust PERIMETER
  • Both PERIMETER and INTERNAL contain user accounts that need to be authenticated and federated via ADFS
  • The ADFS server is joined to the PERIMETER domain
  • ADFS and its related IIS services need to run under a service account from the INTERNAL domain

Here are the high level hoops I had to jump through to get this working:

  1. On a clean Windows 2008 R2 server, obtain and run the ADFS 2.0 setup file AdfsSetup.exe. Select “Federation Server”,  This will install everything you need to make ADFS 2.0 work (including pre-requisites).  Don’t run through the config wizard – We will do the config from command line later.
  2. Create a new service account. e.g. INTERNAL\Svc.ADFS.  Create a new DNS ‘A’ record and point it to the ADFS server. E.g. federate.internal.com. Set a Kerberos SPN for the DNS record against the service account:
     setspn -a HOST/federate.internal.com stjohn\Svc.ADFS
  3. Load the certificates MMC for local computer account and install a certificate which can be used for the ADFS web site. In the IIS manager configure a new binding on the default website for SSL with the appropriate FQDN and select the cert you just installed.
  4. Make sure the ADFS server has access to all LDAP servers for all domains. Something to consider if you’ve got a few firewalls here and there.
  5. Add your service account to the local admins group on the ADFS server and to domain admins group for the domain that the service account belongs to. Don’t panic this will only be temporary! This just allows the service account to create the necessary config for ADFS in the Program Data\ADFS OU. Once created it will have the correct permissions for the service account. I had to do this to get it work, not sure why it’s any different to a normal single forest install.
  6. Log on to the ADFS server with the service account. Skip this step at your peril!
  7. Run cmd prompt as admin. cd to:
    C:\Program Files\Active Directory Federation Services 2.0\
  8. Run the following command to configure and new ADFS 2.0 farm

    FSConfig.exe CreateFarm /ServiceAccount "INTERNAL\Svc.ADFS" /ServiceAccountPassword "somebiglongpassword" /AutoCertRolloverEnabled /FederationServiceName "federate.internal.com


  9. Remove the service account from local admins and domain admins now.
  10. That’s it. Load the ADFS console and configure ADFS as you would in any other scenario

Notes

  • During the install you might get a yellow warning about not being able to set the SPN. That’s cool we already did it above.
  • Make sure you can view the federation data for your new server e.g.
    https://federate.internal.com/FederationMetadata/2007-06/FederationMetadata.xml
  • If you get a certificate error from your service provider. E.g. This typical error from SalesForce:Signature or certificate problems
    Is the response signed? False
    The signature in the assertion is not valid
    Is the correct certificate supplied in the keyinfo? False
    No valid certificate specified in this response.

    T
    ry re-generating your token signing certificate using the following PowerShell commands. Note:This will break any existing trust relationships you have with any service providers. You will have to export the new cert and update your service providers with it.
Add-PSSnapin Microsoft.Adfs.Powershell
Set-ADFSProperties -AutoCertificateRollover $true
Update-AdfsCertificate -Urgent

 

This might not be the only way to get this working and I haven’t tested it thoroughly – your mileage may vary! But as always I’m keen to hear how you get on and happy to field questions.

 

10

iLO 2 Firmware Images, Cursor Keys and IE8

A couple of things I came accross with iLO today:

 

 

Plain Firmware Image .bin Files

I’ve got DL360 G5 running  VMWare ESX 4 and I wanted to update the iLO firmware to the latest version.  Even though iLO has a firmware update page where you can upload a new firmware image file. This doesn’t seem to be available for download at the HP iLO2 support page. To get it you need to download the Windows firmware update tool and extract the package using 7-zip.

 

Remote Console – Cursor Keys Don’t Work with IE8

To get around this, disable protected mode in IE or run it IE as administrator (Windows 7, vista etc).

0

FindPrivateKey.exe (Pre-Compiled)

I don’t really like to do this but here’s a compiled copy of FindPrivateKey.exe.  It’s a really uesful tool but Microsoft only provide the source code as part of a development sample.

Details about the tool are here: http://msdn.microsoft.com/en-us/library/aa717039.aspx

 

Hopefully Microsoft will get annoyed with me distributing this here and put up an official binary.

I compiled it my self this afternoon. At least it’s better than downloading it from some dodgy file-sharing site!

Requires .NET 3.5

FindPrivateKey.exe
Version: 0.0.0.0
Updated: 2011-04-07
Download: FindPrivateKey.exe - 10.5 kB

 

7

HP Lefthand / vSphere: “failed on physical path”

We recently started having issues with our VMWare / HP Lefthand iSCSI SAN environment. The symptoms were as follows:

  • VMs would sometime freeze-up for up to 10 seconds – no ping, nothing!  Really nice on a busy SQL server running finance apps! Yeah! The problem affected VMs on both the Lefthand iSCSI and the fibre channel EVA
  • Taking snapshots of VMs on the Lefthand storage would almost always fail and in most cases make a mess of disk chaining which would require manual clean up
  • Browsing datastores is extremely slow
  • General flakiness across the VI environment (Yes, that is a technical term)

I stated out by looking in the vmkernal logs of the ESX hosts and found errors like this occurring fairly regularly.

Mar 10 18:04:02 myesxsvr01 vmkernel: 1:08:22:15.031 cpu1:4514)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x4100040ebc00) to NMP device "naa.6000eb31749025160000000000016019" failed on physical path "vmhba33:C0:T14:L0" H:0x0 D:0x2 P:0x0 Valid sense data: 0x9 0x4 0x2.

These errors were in relation to LUNs on the iSCSI SAN. A quick google of “failed on physical path  H:0x0 D:0x2 P:0x0 Valid sense data: 0x9 0x4 0x2 Lefthand” quickly turned up this VMWare KB article which states that this is a LUN locking error caused by having VMFS LUNS presented to a Windows host which has the HP Lefthand DSM (Device Specific Module) for MPIO installed. This immediately rang a bell with me because we had recently installed a new backup server including full iSCSI MPIO support using the HP DSM.

Presenting the LUNs to the backup server allows VMs to be backed-up directly from the LUN as opposed to backing up via one of the ESX hosts.  A good idea as long as you read the HP documentation all the way to the end and don’t install the DSM for MPIO!

 

Great! I thought, I’ve found the problem.  It appears the the LUN is being locked by the DSM and is causing the host to “timeout” affecting the entire storage subsystem (iSCSI and Fibre Channel).  I went ahead and un-presented the iSCSI VMFS LUNs from the Windows host fully expecting the issues to clear up.  Unfortunately this didn’t happen.  My next step was to vMotion all the VMs off one host and reboot it.  Still no luck, the errors returned to the vmkernal logs within a few minutes of the reboot.

At this point I logged a case with HP who provide our VMWare (and of course Lefthand) support.  After they analysed the logs, they felt that the only way to resolve the issue was to do a full shutdown of the all the hosts and all the Lefthand storage!  Classic support call – “Have you tried turning it off and back on?” But seriously, the guy at HP was very knowledgeable and helpful.  We proved the approach as follows:

  1. Create a new LUN on Lefthand and present it to all ESX hosts
  2. Put a VM on the new LUN and prove that there are no issuers associated with the LUN by repeatedly taking snapshots and monitoring the vmkernal log
  3. Present the LUN to the Windows backup host with the MPIO DSM. – Now the errors start occurring with this new LUN.
  4. Un-present the LUN from ALL hosts (ESX and Windows)
  5. Reboot one of the ESX hosts and re-present the new LUN to it. – The errors are no longer occurring with this LUN

It appears that access to a LUN from all hosts must be stopped to clear the locking so we did a fair amount of planning and undertook a full shutdown as follows:

  1. Uninstall HP Lefthand DSM for MPIO from Windows hosts (We still want to try to present the VMFS LUNs back to the backup server at some stage)
  2. Shutdown all VMs
  3. Shutdown all the ESX hosts
  4. Shutdown Lefthand (Shut down the management group, not the nodes individually)
  5. Power up the Lefthand and make sure all the nodes are up and volumes are all online
  6. Power up the ESX hosts and VMs

After doing this all LUN locking errors are gone from the logs.  Everything seems very solid, snapshots are working and the flakiness is gone!

Any comments from anyone who has an understanding of the inner workings of iSCSI, lefthand, VMWare SCSI reservations/locking etc who can shed some light on what’s actually happening here would be much appreciated! Or just if you’ve had a similar experience I’d be keen to hear.

Thanks for reading

4

When to Create a New LUN (The hp way!)

I know it’s not meant as a definitive technical guide but I had a good laugh when I came across this flow chart in hp’s LeftHand SAN / VMWare vSphere 4 guide.

 

Or in engineering speak: “Tighten it up ’til it breaks then back it off half a turn!”

 

Sorry if you dropped by with a legitimate question on LUN management! Actually the question in the chart about snapshots and remote copy is very valid and the very first thing you must consider when designing your LUN layout.

 

2

Citrix Web Interface with ISA Single Sign On

It’s been a long time since my last post!  I’ve been so busy working on the house (but nothing really blog-worthy).  Anyway today a colleague and I went through and set up the Citrix Web Interface (5.x) with single-sign-on using Microsoft ISA 2006.

The Web Interface and Secure Gateway run on the same server but are configured completely independently of each other, they could just as well be on separate servers if the load warranted it.  They both listen on port 443 on separate IP addresses with separate certificates.

On the face of it, it seems quite straight forward – configure the Web Interface for pass-through authentication, create an ISA web publishing rule using our common SSO web listener with forms based authentication and configure an authentication delegation method.  This works just fine as far as getting the user logged in with their list of applications.

Next step – configure the CSG to listen on a separate IP address with a separate certificate and configure a NAT rule so the ICA client can connect directly to the CSG.  Again fairly straight forward.

Here’s the catch. Using pass-through on the web interface doesn’t work with the CSG.  Pass-through mode expects the client to be domain-joined, inside the corporate network and able to authenticate directly with the XenApp Server (as opposed to being pre-authenticated by the XML/STA services).  The result with the above configuration is that when the user launches an application they are presented with a Windows login dialog which defeats the purpose of single-sign-on.

The solution – ASP.Net “jump” page on the web interface.

Configure the Web Interface in “Explicit ” mode rather than pass-through.  This is the standard method where the user is presented with the Citrix Web Interface login form.

Configure the ISA web publishing rule to delegate “basic” credentials. i.e. clear text user-name/password (secured with SSL of course!).

Create an ASP.NET jump page which extracts the user-name and password from the HTTP request, and creates a form with hidden fields then uses java script to POST the form to the Web Interface login page.

This all happens instantly without the user noticing.  Don’t configure the Web Interface as the default IIS page, instead place the jump page in the root of the IIS web site and set the document priority to to serve it up first.  Here’s the code:  (Download link at the end of the post)

AuthPass.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="AuthPass.aspx.cs" Inherits="AuthPass" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>
		</title>
	</head>
	<body onload="submitlogin()">
		<div id="FormContainer" runat="server">
 
		</div>
	</body>
</html>
 
<script type="text/javascript" language="javascript">
	 function submitlogin()
	 {
		document.CitrixForm.submit();
	 }
</script>

AuthPass.aspx.cs Note: The domain field needs to be set to your own domain or removed completely depending on how your users login.  The form action needs to point to your Web Interface login.aspx page.

using System;
using System.Net;
using System.Text;
using System.Web;
 
public partial class AuthPass: System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
		FormContainer.InnerHtml = doLogin(Request.ServerVariables["AUTH_USER"],Request.ServerVariables["AUTH_PASSWORD"]);
	}
 
	private String doLogin(String strUser, String strPassword)
	{
		StringBuilder strForm = new StringBuilder();
		strForm.Append("&lt;form name=\"CitrixForm\" action=\"https://citrix.corp.com/Citrix/XenApp/auth/login.aspx\" method=\"post\"&gt;");
		strForm.Append("&lt;input type=\"hidden\" name=\"domain\" value=\"MyDomain\"&gt;");
		strForm.Append("&lt;input type=\"hidden\" name=\"user\" value=\"{0}\"&gt;");
		strForm.Append("&lt;input type=\"hidden\" name=\"password\" value=\"{1}\"&gt;");
		strForm.Append("&lt;input type=\"hidden\" name=\"LoginType\" value=\"Explicit\"&gt;");
		strForm.Append("&lt;/form&gt;");
		return String.Format(strForm.ToString(), strUser, strPassword);
	}	
 
}

Here are the key points.

ISA 2006

  • Web publishing rule with SSO WebListener using forms based Authentication
  • “Basic” authentication delegation  (SSL end to end!)
  • Published logoff URL is set to /Citrix/XenApp/site/logout.aspx
  • Simple NAT rule for CSG

Web Interface

  • A new XenApp site is created in the Web Interface Management tool with “At Web Interface” configured for the “Where user authentication takes place” setting
  • Authentication Method set to Explicit
  • AuthPass.aspx[.cs] files are placed in the root of the IIS website to handle auto-login
  • XenApp web site is not configured as the default IIS site.  AuthPass.aspx is set as the default page on the IIS web site
  • Secure access mode is set to “Gateway Direct” but this will depend on your environment

CSG

  • This CSG is entirely configure using the CSG Management Console
  • A specific certificate for the CSG is selected
  • The CSG is set to listen on specific IP address rather than the default of all IPv4 addresses (an additional address must be added to the server’s TCP config).
  • “Direct” mode is configured for the Web Interface location

There you have it.  Citrix WI/CSG SSO for ISA.  I know it’s a bit of a hack but I spent some time trying to find a way to do this natively with Citrix Web Interface configuration and posted in the Citrix support forums without any success.  If there is a more official way to do it I’d love to hear about it.

On a side note…

I found a long delay during login which was fixed by disabling NetBIOS over TCP/IP on the web interface server

Citrix Web Interface SSO for MS ISA
Version: 1.0.0
Updated: 2011-02-17
Download: AuthPass.zip - 1.09 kB

Exchange Resource Mailboxes Schedules – “No Information”

Here’s a quick one that might save you some time.  Even after installing the Exchange auto accept agent and registering your resource mailboxes against it you still don’t get free/busy information when you go to book the resource.

If these are new resource mailboxes which haven’t yet had a booking all you need to do is create a booking and the free/busy information will start working.

1

Modular vbScript Framework

Here’s a modular vbscript framework I wrote for deploying software and performing other multi-step tasks across reboots.

I won’t list the whole script in the post because it will get messy with all the wrapping.  Instead I’ll just describe the main features and you can download the zip file below.  The screenshot will also give you a reasonable idea about how it works.  It’s a bit rough and doesn’t have robust error handling – it’s really just to give you some ideas about putting together modular vbscripts.

The main script is a .wsf (Windows script file).  I use WSF because you can’t include other script files in a .vbs file.  The framework gives us the following benefits:

  • Code reuse – We can write core functions that are available across all modules
  • Modular development – We can create and maintain modules in isolation
  • Extensible  – It’s easy to add new functions and modules
  • Scripty goodness over unattended reboots/logons
  • Log file generation

Here is the file/folder structure of the framework:

\RGFramework.wsf <-Main script logic file
\includes\header.vbs <-Header file to declare variables etc
\includes\Corefunc.vbs <-Functions which are available across all our modules 
\Modules\(ModualName)\(ModualName.vbs) <-Module files
 

Script logic

Here’s an example of typical framework logic:

  1. Start a continuous loop
  2. Get the step which we’re up to from the registry. Registry key doesn’t exist yet  (Step 0)
  3. The Select statement executes the code for step 0
    1. Set the script to run next time windows starts
    2. Set auto-logon so Windows logs on automatically when it boots up
    3. Run a module e.g. InstallOffice()
    4. Call “NextStepReboot()”. The current step is recorded in the registry and the system reboots
  4. The system has rebooted and logged on automatically and the script starts again
  5. Get the step which we’re up to from the registry (step 1)
  6. The Select statement executes the code for step 1
    1. Run another module .
    2. If we don’t need a reboot then we’ll just call NextStep() to record the step we’re up to
  7. The code loops back around to the select statement and we now go to step 2
    1. Run another module function
    2. Clear auto-logon
    3. clear script start-up
    4. exit

Note*

To start the script from the beginning again or from a specific step ‘the “HKLM\SOFTWARE\RGFramework\Step” registry string must be deleted or manipulated.  This string represents the last step that was run so if it is set to 3 then next the script runs it will execute step 4.

Modules

A module is just a file which contains a single function.  The function has the same name as the module file. Here is an example of a module which installs an application. (\modules\installMyApp\installMyApp.vbs)

Function installMyApp
objShell.run strInstallSource&"\MyApp\myapp.exe /quiet", 1, true
End Function

The module is added to the main script logic file with the following directive.

<script language="VBScript" src="\modules\installMyApp\installMyApp.vbs"/>

The module is executed by simply calling the function during one of the steps.

installMyApp()

If you have any questions ask in the comments and let me know if you want more stuff like this 🙂

Here’s the zip file which contains the script structure and code.

RGFrameWork
Version: 0.1
Updated: 2010-12-14
Download: RGFrameWork-0.1.zip - 4.34 kB
3

Cheatsheet: Add HP Lefthand Storage Nodes

Here are the quick high level steps for adding new storage nodes (P4000, P5400 etc) to your HP Lefthand iSCSI SAN (AKA StorageWorks P4000).

  1. Install and cable the units
  2. Check the HP site for firmware updates and apply ONLY the recommended updates
  3. Configure iLO so you don’t have to spend so much time in the cold room (optional)
  4. At the console on each unit give the first NIC an IP address. You can leave the other one disabled for now.
  5. Download and install the latest SAN/iQ Centralized Management Console on your workstation or management server
  6. In the CMC add the new nodes by going “Find Systems” and entering the IP addresses you assigned to the nodes
  7. Under “Available devices” go to the TCP/IP settings of each node and create a bond so the two NICs become one and choose a load balancing type.
  8. Go to http://webware.hp.com/ and generate your license keys. Each unit comes with an entitlement certificate. You’ll need to provide the Feature Key (MAC Address) which can be found in the CMC under “Feature Registration” for each node.  When you get the key replace the one that’s in there by default.
  9. Right click the units and add them to an existing management group (or create a new one)
  10. Now that You have the units in the management group add them to an existing cluster (or create a new one)

Nodes must be of equal or greater capacity to existing nodes in a cluster.  If they are of greater capacity then only the capacity of the smallest node in the cluster will be usable – Maybe time to create a new cluster?

I’ll let you fill in the detail but that’s basically it.

3

PPTP VPN & Citrix client drive mapping fails behind belkin router

Pic:Belkin F5D8635I came across this today. I’m not sure what’s causing it or how to fix it and probably won’t get a chance to dig any deeper but thought I’d comment anyway.

A Citrix web client sitting behind a Belkin F5D8635 wireless/ADSL router doesn’t get his local client drives mapped in his session. This is seen with several Citrix client versions, server version MPS 4.0 an 4.5.

This has been observed on two separate Belkin routers of the same model.

I’ve also noticed that trying to establish a Microsoft PPTP VPN connection from a client behind this router also fails.

* Update *

Belkin has now has a pre-release firmware which they say fixes the PPTP problem. I haven’t tested it yet so can’t confirm whether it fixes the Citrix drive mapping issue.

0

ISA Not Enough Memory (0x80070008)

I came across this one today when one of our web apps in the perimeter network stopped working for external users after a switch failure on our internal network.

We run split DNS so if you ask an internal DNS server for the IP address of webapp.ourdomain.com it will tell you the private address of the perimeter webserver but if you ask a DNS server on the internet you will get the public address which is NAT’d to the ISA server which publishes the app. Now if you ask a DNS server in the perimeter network he will forward the DNS request to an internal DNS server. If the internal DNS server is unavaliable the perimeter server will use recursion to resolve the address and ultimatily end up resolving and caching the public address of the webapp. By now you can probably guess what happens.

  1. Internet user connects webapp.ourdomain.com which is resolved to 203.271.47.15
  2. The connection is NAT’d by our external hardware firewall and  received by the ISA web listener / publishing rule.
  3. The ISA server resolves the name in the “To” section of the web publishing rule using a perimeter DNS server. The address is from the internal domain (ourdomain.com) so the perimeter DNS server tries to forward  the request to an internal DNS server, this fails so the perimeter DNS server uses recursion to resolve the name and returns the public internet address instead of the private address of the web server in the perimeter network. We now have a loop which results on the above error being logged.

There are a couple of ways to deal with this.

  1. Disable recursion on the domain forwarding in the DNS server settings:
  2. Explicitly specify the IP address in the “To” section of the publishing rule.

Another one of those “Only in this exact and unlikely situation” type posts but oh well!

0

MOSS Split Back-to-Back in the Real World

I’ve realised that I’m just not going to have time to complete my MOSS back-to-back series in the way I started out in Part 1 so instead I’m going to combine everything in a single post based around my original documentation and go from there. Please feel free to ask questions, I’ll answer them to the best of my ability and continue to add detail to this post.

I found the Microsoft SharePoint extranet deployment documentation pretty lacking; from what I could find they don’t go much further than: “here are a few ideas, have fun!” Well I did have fun! And as always with these things the devil is in the details.

Objectives

Primary objective – Making SharePoint available over the internet

  • A single URL for external users and internal corporate staff regardless of where they access SharePoint from
  • External member accounts contained in a separate domain to internal corporate staff accounts
  • Access secured with publicly trusted SSL certificate
  • Full backend access and functionality for corporate staff

Secondary Objectives

  • Implement single sign-on, forms based authentication and reverse proxy for all web-based applications hosted in the perimeter network

Guiding Principals

  • Internal users logged on to internal workstations are seamlessly authenticated to the MOSS site
  • Internal users accessing the MOSS site from the internet are presented with a forms-based logon screen; they authenticate using the same username and password as they do for internal workstation logon
  • The same URL is used whether the MOSS site is accessed from internal network or the internet
  • Perimeter (non-staff) users access the MOSS site from the internet using an account from the perimeter domain
  • Perimeter users cannot logon on to an internal workstations and cannot access internal resources.
  • Both internal and perimeter users access the same MOSS site
  • Both internal and perimeter users can reset their password from the forms-based logon page
  • Once users have logged on they can navigate to other applications without having to enter their username and password again.
  • The perimeter domain trusts the internal domain
  • The internal domain does not trust the perimeter domain
  • MOSS WFE applications in the perimeter can use Kerberos to delegate credentials of internal users to other applications on the internal domain, so internal users have access to all the same resources regardless of whether they are access from the internet or from an internal workstation

Solution Overview

The solution is built on a back-to-back firewall topology, it uses forms based pre-authentication and server publishing technologies available in Microsoft’s ISA Server 2006. While the hardware firewall is the first point of entry from the internet the MS ISA firewall in the perimeter network should be considered the “front firewall” as it deals with server publishing and user authentication.

From a MOSS 2007 point of view the Microsoft Split back-to-back topology scenario has been followed; MOSS web front-end servers are located in the perimeter network while the application and database servers reside in the internal network.

A one-way Active Directory trust exists between the perimeter domain and the internal domain. This is a non-transitive trust where the perimeter domain trusts the internal domain but not the inverse. This serves two main purposes; it allows windows authentication and delegation to occur between services in the perimeter domain and the internal domain and at the same time protects sensitive data such as payroll databases on the internal network.

Solution overview Diagram

The existing internal network
Forest with 2 domains:

  • corpforest.com (empty forest root domain)
  • corp.com (internal production domain, contains accounts for all corprate staff)

The new perimeter network
Forest with a single domain:

  • perimeter.corp.local (perimeter production domain, contains accounts for all members and external collaborators)
  • Authenticates users from both perimeter domain and internal domain via domain trust

Authentication

Identity and Single Sign On

Everyone who accesses applications in the perimeter falls in to one of the two following categories; these categories determine which domain the user account is created in.

Internal Corporate Staff:
Users that require access to perimeter applications such as SharePoint but also require access to internal resources/applications such as Citrix, payroll / finance databases, and Exchange Email. These users reside in the current corp.com domain

Members:
Users that require access to perimeter applications such as SharePoint but do not require access to internal resources/applications. These users will reside in the new perimeter domain (perimeter.corp.local). External vendors / collaborators also fall in to this category

The ISA server in the perimeter domain is configured to support single-sign-on of users accessing applications on the corp.com DNS name space. This means that a user who logs in to one application will be able to follow a link to another without having to re-authenticate. E.g. A user logs on once to sharepoint.corp.com and can then hop to outlook.corp.com then to citrix.corp.com all without having to re-enter their username/password.

Forms Based User Authentication

Users who access web applications from the internet must first authenticate at the front MS ISA firewall. When a user attempts to access a web application (e.g. SharePoint – https://sharepoint.corp.com) in the perimeter network he will first be presented with a forms based (HTML username/password) authentication page at the ISA server. At this point the user can enter a credential from either the perimeter domain or from the internal domain. Once the user’s identity is validated the ISA server will proxy the application to his browser.

Authentication Protocols

The diagram below outlines the steps taken to authenticate and or delegate user credentials. Basic authentication is used from the ISA server to the published destination IIS server. This is done because cross forest Kerberos delegation is not supported by ISA server. Even though the IIS server is a member of the same domain as the ISA server, the IIS application pool is running under a service account from the internal domain, which is done to facilitate windows authentication from the application to the backend database server on the internal network.

The basic credentials are secured using SSL between the ISA server and the destination server.

Once the basic credentials reach the published IIS server it will use Kerberos to authenticate the user against the appropriate domain. Using Kerberos at this stage means that user’s credentials can be delegated to a backend server e.g. SQL Server Reporting Services. The result is that internal users get exactly same experience outside the network as they do inside.

User Authentication

Internal User

  1. Username / Password from browser sent in clear text (over https) (FBA)
  2. ISA pre-authenticates user with internal DC via using LDAPS
  3. ISA delegates basic credentials (over https) to MOSS IIS server
  4. MOSS IIS authenticates user using Kerberos to internal DC
  5. MOSS IIS server delegates Kerberos authentication and impersonates user

Member

  1. Username / Password from browser sent in clear text (over https) (FBA)
  2. ISA authenticates user with perimeter DC via LDAPS
  3. ISA delegates basic credentials (over https) to MOSS IIS server
  4. MOSS IIS authenticates user using Kerberos to perimeter DC
  5. Delegation fails due to one-way trust. Internal domain doesn’t trust perimeter domain

Configuration

Network Configuration

Networks

Internal : 192.168.33.0/24
Perimeter : 172.16.0.0/16
DMZ : 10.1.1.0/8
Public : 258.17.84.128/28

Network relationships

As shown in the diagram a route relationship is defined between the perimeter and internal network instead of a NAT relationship, this is required to facilitate the domain trust relationship and Kerberos authentication between the two domains.

Network Relationships

Routing

All perimeter servers specify the front firewall (ISA02) as their default route

To maximize routing efficiency a persistent static route from the perimeter network to the internal network via the back firewall (ISA01) is added to all perimeter servers. The following command is run during initial server build.

route add 192.168.0.0 mask 255.255.0.0 172.16.1.1 –p

IP Addresses

HW Firewall Internal IF : 10.1.1.254
ISA01 External IF : 10.10.1.1
ISA01 Perimeter IF: 172.16.1.254
ISA02 Perimeter IF : 172.16.1.1
ISA02 Internal IF : 192.168.33.254
WFEVIP1 (SharePoint WFE farm load balanced virtual IP): 172.16.1.50

Network Address Translation

Public access from the internet is NAT’d via the hardwre firewall. The diagram below shows the complete network path taken by a user when accessing the a web app from the Internet. Note the web listener listens on multiple IP addresses. Multiple web publishhing rules use this web listener.

NAT

Back Firewall

Firewall Policy

This following table shows the firewall policy on the back firewall (ISA02) that relates to communication between the internal network and the new perimeter network e.g. MOSS frontend/backend/database access. Kerberos, LDAP etc.

This represents the bare minimum of rules as they relate to this document, you’ll certainly have your own additional rules.

Click for an MS Word Version!

Click for an MS Word Version

Front Firewall

Web Publishing Rule Configuration

A single ISA SharePoint publishing rule is used to publish the load balanced MOSS web front end servers. Configuration can be considered default as per the MS ISA SharePoint publishing rule unless detailed below.

Destination server (To)
The FQDN of SharePoint (sharepoint.corp.com) is specified; this resolves to 172.16.1.50 which is the virtual IP address of the load balanced cluster of MOSS WFE servers. We choose to forward the original host header since the internal and external names are the same. Requests must appear to come from the original client otherwise load balancing based on IP address won’t work.

Web Publish "To" Tab

Listener

The listener selected (Perimeter Web Listener) is used by all FBA based applications in the perimeter network; this enables SSO functionality.

Webpublish Listener selection

Public Name
The public DNS name used to match the publishing rule.

Web publish public name

Bridging
Connections to the internal servers are only made via SSL, and on the default port (443).

Web publish Bridging

Authentication Delegation
Credentials are delegated to the target server using basic authentication. Detailed information on why basic delegation is used can be found in the Authentication Protocols section under Solution Overview.

Web publish authenticaion delegation

Web Listener / Pre-authentication

This section describes the ISA https web listener and forms based authentication configuration. ISA 2006 web listener defaults should be assumed unless described below.

Networks

All IP addresses that the web listener will listen on are selected here. There is a separate address defined for each application that makes use of this web listener. Traffic is NAT’d by the hardware firewall from public IP addresses to these DMZ addresses. e.g. the public IP address resolved by sharepoint.corp.com is 258.17.84.142 and is NAT’d to 10.1.1.142

Web listener Networks

Certificates and SSO

An individual certificate is assigned to each application’s DMZ IP address. This allows multiple SSL secured applications to use the same web listener which consequently means that single sign on can be used across all these applications.

Certificates

Single sign on is enabled for applications on the corp.com DNS suffix.

Web listener SSO Domain

Connections

http is redirected to https. The good thing here is that http links that that get emailed around when people are working at the office also work when they access from the internet.

Web listener connections

Forms

The path to the customised html logon form is specified here as well as the options to allow users to change their passwords and password expiration warning.

Web listener formsAuthentication

When users first request an application that is using this web listener they must first be authenticated by the MS ISA server before they are allowed to proceed to the requested application. HTML forms based authentication is used for this initial step. This is where user enters their username and password.

As shown in the screenshot LDAP is used instead of native windows authentication; this is due to an issue with password changes in a cross domain scenario. During testing it was discovered that when using Windows authentication it is not possible for a user to change their password at the HTML logon page if their account is in a different domain to the ISA server. This is problematic especially for seldom used accounts where the password expires or for new accounts where the administrator needs to force the user to change their password at next logon.  Microsoft ISA 2006 SP1 introduces a bug which also affects the change password functionality when using LDAP authentication, a non-public patch has been released to fix this bug; for details see the known issues section of this document.

Two LDAP server sets are used, one for the perimeter domain controllers and one for internal domain controllers.

Logon expressions are mapped to the LDAP server sets. How users prefix their username determines which LDAP server set is used to authenticate them. The following config uses “*” wild card to allow the concept of a default domain. If the login starts with “corp\” then the internal LDAP set is used other wise it default to the perimeter set. This means that anyone who has an account in the perimeter domain doesn’t need to specify a domain.

Web listener authentication

Two LAP servers (domain controllers) are defined for each LDAP server set. For password change functionality to work, a secure connection must be used (LDAPS) and the “Use Global Catalog” option must be turned off. A lookup account in the target domain must also be made available for the ISA server. This is a non-privileged account with a very strong, non-expiring, set/forget password which is set during configuration.

A secure SSL LDAP connection requires that port 636 be open to the internal domain controllers on the back firewall, this is noted under the “back firewall” configuration earlier in this document.

A server certificates must also be installed on the domain controllers and must be trusted by the ISA server. This can be acheived by setting up a CA (certiificate Authority) but that’s out of scope for this post.

I will however point out a good tip for testing that the ISA server is correctly trusting the DC and is able to make an LDAPS connection. Use the ldp.exe tool from the Windows Server 2003 resource kit and make a connection on port 636 with SSL enabled. If everything is working correctly then it will connect without error otherwise it will throw some kind of TLS error.

Web listener LDAP server sets

Active Directory Trust Configuration

A one-way domain trust is configured between the corp.com domain and the perimeter.corp.local domain. This is done to allow internal accounts to be used in the perimeter domain which inturn enables windows authentication to be used when accessing backend resources such as SQL databases. This trust means that deploying MOSS web front end servers is as straight forward as adding the web front end role, all IIS configuration is completed by MOSS and remains valid in both the internal and perimeter domains.

Trusts(perimeter)

Trusts(internal)

Now you might be wondering why we don’t use a forest trust. Well the truth is I had issues with using a forest trust and if anyone can shed any light on this I’d be very interested. I’d love to set this back up in the lab but I can’t see my self getting time.

Here’s the situation. On the internal side we have an empty forest root domain of corpforest.com inside that forest we have the internal production domain called corp.com. On the perimeter we have a single forest/domain called perimeter.corp.local. We create a one-way forest trust (which is transitive) between corpforest.com and perimeter.corp.local. We then take a member server in the perimeter.corp.local domain install MOSS and join it as a webfront end to the MOSS farm based in the internal network.  This will automatically create IIS MOSS web apps and application pools. These application pools are set up identically to the ones on the internal MOSS servers so of course are configured to run under internal service accounts.

Everything seems to be working correctly the application pools run fine but when trying to browse to the site IIS writes an error: “The caller is not the owner of the desired credentials”. Despite many hours of digging through logs, traffic sniffing and bashing my head against the desk I was unable to get IIS to work with a service account from another domain when using the forest trust, except if I used an account from the root domain of the trusted forest which is not ideal as all internal MOSS IIS servers would need to be re-configured. I should mention that this is not an issue specific to MOSS, it’s an IIS issue in general. I stood up another IIS/ASP.NET/Visual Studio test box in the perimeter and it had the same problem.

If both your internal and perimeter domains are single forest/domain I expect you might not have any issues and I’d be very interested to hear your results.

SharePoint

This section only describes MOSS configuration that relates to the perimeter network deployment.

People Picker

To enable the “PeoplePicker” in a one-way trust scenario to search both domains (perimeter and internal) the following stsadm commands must be run.

On all servers in the farm:

stsadm -o setapppassword -password “(password)”

(Where “password” is a strong password shared between the servers.

On all web front end servers:

stsadm -o setproperty -url http://sharepoint -pn
"peoplepicker-searchadforests"
-pv "domain:perimeter.corp.local",
PERIMETER\PeoplePickerService, (Password)

(Where “Password” is the password for the unprivileged service account “PeoplePickerService” used to perform lookups on the perimeter domain)

AAM (Alternate Access Mappings)

Zones

The following access mappings / zones are configured

AAM Zones

Internet users only access sharepoint over SSL in the default zone via https://sharepoint.corp.com

Internal users access sharepoint over plain http in the intranet zone via http://sharepoint.corp.com. This is the default home page for all internal users as set by group policy. Plain HTTP is used for internal users to ensure optimum performance especially across the WAN where the Certeon accelerators are deployed. The URL http://sharepoint is also valid for internal users.

Some SQL Server Reporting Services (SharePoint Integrated Mode) features only work when accessed in the default zone hence internal users wanting to access these features will need to access sharepoint in the default zone via https://sharepoint.corp.com. See the known issues section for more information.

Known Issues

MS ISA Forms Based Password Changes

Valid Account Discovery Vulnerability

A patch in ISA 2006 SP1, as means to fix a security vulnerability broke password change functionality when using LDAP authentication. (http://support.microsoft.com/kb/957859/). This has been fixed by non-public patch KB959357 (http://support.microsoft.com/kb/959357). Unfortunately this patch re-introduces the security vulnerability.  This Vulnerability means that when an incorrect password is entered for a valid account and the account is in a password-expired state, a change password form is displayed; while the correct old password must be specified before a new one can be set this could allow an attacker to discover that an account name is valid by brute force. This can be considered a low risk vulnerability which is out weighed by the need to allow users to change their own password. Hopefully Microsoft will fix this issue in the next major service pack. Below is a summery of the vulnerability behaviour.

ISA Change Password Vulnerability

Password length / Complexity Policy

When a password is changed using the ISA FBA change password tool the password complexity is checked against the domain that the ISA server is a member of. This means that both the internal and perimeter domains must have the same password complexity / length requirements to ensure consistent behaviour for end users. -I need to confirm this one!
SSRS in SharePoint Default Zone Only

When using SQL Server Reporting Services in SharePoint integrated mode some methods of viewing reports are only supported in the default zone. For example, if you try to open a report from a document library while accessing the sharepoint on http://sharepoint.corp.com (intranet zone) instead of https://sharepoint.corp.com (default zone) you will be presented with the following error.

The specified path refers to a SharePoint zone that is not supported.
The default zone path must be used.

The report viewer webpart works correctly regardless of what zone it is accessed in.

Step

St John Internal WAN User

St John Member

1

Username / Password from browser sent in clear text (over https) (FBA)

Username / Password from browser sent in clear text (over https) (FBA)

2

ISA pre-authenticates user with St John DC via the domain trust

ISA authenticates user with perimeter DC

3

ISA delegates basic credentials (over https) to MOSS IIS server

ISA delegates basic credentials (over https) to MOSS IIS server

4

MOSS IIS authenticates user using Kerberos to St John DC via forest trust

MOSS IIS authenticates user using Kerberos to perimeter DC

5

MOSS IIS server delegates Kerberos authentication and impersonates user

Delegation fails due to one-way trust. Perimeter trusts STJOHN only.

18

RDP through a firewall fails with: “The RPC server is unavaliable”

This is just a quick one…

When trying to logon to Windows server 2003 via remote desktop you receive the following message:

The system cannot log you on due to the following error:
The RPC server is unavailable.
Please try again or consult your system administrator.

RCPError

You will also receive the following event in the target server’s application event log:

Event ID: 1219
Logon rejected for Domain\User. Unable to obtain Terminal Server User Configuration. Error: The RPC server is unavailable.

Event ID 1219


There are a number of reasons you might see this message but in my case it was because the server I was connecting to was behind a firewall and in different domain to the one which my account was in.

When you logon via RDP, “Terminal Services” will contact the domain which your account is in to query terminal services information about your account e.g. profile path. It does this using RPC to a domain controller.

In my case the server concerned was in the perimeter network and there was no way I was going open RPC on the firewall to allow it to talk to an internal DC. And since the purpose for RDP to this server was purely for administration I really didn’t care if it couldn’t get my profile info from AD.

Fortunately there is a workaround as described in this Microsoft article, actually the article refers to a different problem, but the workaround is the same.

http://support.microsoft.com/kb/815266

  1. Locate the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
  2. Create a new DWORD called IgnoreRegUserConfigErrors
  3. Give it a value of 1

Done! I might consider creating a group policy preference to implement this across all the servers in the perimeter domain.

8

MOSS 2007 SSRS WMI provider error

Setting up SQL Server Reporting Services in SharePoint integration mode and you turn up with this error when you try to “Grant Database Access” from within Central Administration:

Unable to connect to the Report Server WMI provider

grantdberror

If you’ve got an ISA firewall between your MOSS central admin and your SSRS server you’ll need to turn off “Strict RPC Compliance” just while central admin performs the “Grant Database Access” operation .

isarpcsettings

Hope this saves someone some time. Not a very common scenario I guess.

0

IE GPO Zone Templates and the “Open File – Security Warning”

Since you’re reading this you probably already know that Internet Explorer has a number of security zones. URLs are treated differently depending on the zone they fall into. These security zones apply not just to URLs in Internet Explorer but to windows in general e.g. accessing files from a network location. My specific problem was a GPO start-up script that ran backinfo to display the server info on the desktop when an admin user logs on. Backinfo.exe an unsigned application stored on the netlogon share would throw the Open File – Security Warning every time it was launched. More about that soon.

Open File Security Warning

In the enterprise it’s desirable to configure all these zone and security settings using group policy but there are a few gotchas that can make the configuration and testing process a bit confusing.

gpo

A standard zone template can be applied to a user’s settings. After you apply this template you can do a gpupdate /force/target:user; you won’t get a warning about logging on/off. Now in Internet Explorer you’ll notice a couple of things. (1)The security level and visual slider for the zone on the security page will not have changed and will not reflect the template you’ve selected in the GPO. (2)If you click on “Custom level” you’ll see that the individual settings that the selected template represents are in fact set and are now unchangeable, i.e. the policy has applied.
securitypage

Ok so at this point we could be forgiven for assuming that the policy has been fully applied to the system; we can see the changes in IE and we know that gpupadte didn’t ask us to log off/on.

Now on to the “Open File – Security Warning “, this is affected by the setting pictured above, “Launching applications and unsafe files”. Since this is a trusted zone we trust all the locations in this zone so we are happy to launch unsigned applications without a security warning. For some strange reason this setting is one of the only ones that can’t be set individually with group policy, the only way to set it (via GPO) is to apply a template as described above. Both “Low” and “Medium Low” will allow applications to launch from a network location without a security warning.

The thing that’s really confusing is that even though doing the gpupdate updates the policy in IE it is not fully applied to the reset of the system until you log off/on.

In Conclusion

  • Security templates are not visually reflected in the security page of Internet Explorer even though they are applied.
  • Security zone settings are applied to Internet Explorer by doing a gpupdate but a log off/on is required to apply these settings to the rest of the OS
  • The “Launching applications and unsafe files” setting determines whether the “Open File – Security Warning” dialog is displayed when launching applications from a given location
  • The “Launching applications and unsafe files” cannot be set with a an indvidual GPO setting. (You could create a custom adm file though)
  • When setting zone security via GPO I recommend making the Internet Explorer security page invisible to users to avoid confusion as they can still quite happily adjust the security level slider, it just won’t have any effect!
0

Deny yourself access to a Group Policy

When clicking too fast you accidentally denied “Full Control” to “Authenticated Users” for a Group policy you were working on. Since deny takes precedence over allow the results are that you are now denied the ability edit the GPO at all. This includes editing permissions to remove the blundered Access control entry! In the Group Policy management console it Looks like this:

GPO

Components of a Group Policy Object

A GPO is made up of two parts; a set of files in sysvol and an Active Directory object. When correcting GPO permissions you must modify the ACL on the AD object using DSACLS (included in the w2k3 support tools) and the sysvol NTFS permission.

The following dsacls command will remove the offending deny ACE from the ACL, in this case “Authenticated Users” from the AD object. The object is named by the GUID that can be seen on the inaccessible object in the GPMC.

dsacls cn={3EE757FE-B5A4-4D23-937D-A3AF5G7F0CEA}, cn=Policies, cn=System, dc=wordpress, dc=com /R “Authenticated Users”

If successful this command will return a full list of the permissions for the object

Next up you need to remove the deny ACE from the policy’s NTFS folder ACL. Again the GUID of the policy is used to name the folder:
\wordpreessSysvolwordpress.comPolicies{3EE757FE-B5A4-4D23-937D-A3AF5G7F0CEA}

NTFS ACL

At this point your GPO will be accessible within the GPMC and the permissions will be consistent across AD and Sysvol. All that’s left to do is to add “Authenticated Users” back to the GPO. Do this by editing the GPO with the group policy editor; doing so will apply permission changes to both the AD object object and the Sysvol policy folder.

Just thought this might help someone, not that it’s ever happen to me! ;-p

1

Bulk replace owner / permissions on user’s server based home directory

This is useful if you want to start using quotas and all home drives are owned by local administrator. Or when you just want to tidy-up/reset access control on users home dirs.

Bulk replace NTFS owner using folder name

– Get subinacl.exe
-Run:
for /d %%i in (*) do subinacl /errorlog=subinacl.err /subdirectories %%i*.* /setowner=%%i

Bulk replace NTFS permissions using folder name

-Get SetACL.exe
-Run:
for /D %%u in (*.) DO SetACL.exe -on %%u -ot file -actn ace -ace “n:domain%%u;p:change” >>log.txt

1