I'm in the process of trying to configure Kerberos Constrained Delegation in ISA 2006 for a Web Server which will use Client Certificate Authentication.
I found this article over at Technet which i thought was very useful.
A more reliable way of remembering useful IT things that I encounter with an added sprinkle of poor grammar.
21 May 2009
13 May 2009
WSUS 3.0 SP1 Clients Being Overwritten
We've recently deployed WSUS 3.0 SP1 at work and found an interesting issue regarding our Virtual Machines. It appears that the VM's were overwriting eachother in the WSUS console.
We did a little reading and found this by Stephen Farrar. It appears that the Sysprep process that we used to commission our VMs on ESX does not strip out the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId] entry in the Registry and therefore all of our VMs have the same ID.
I've written a VBScript which first of all deletes the key, stops and starts the Automatic Updates service and then forces the client to re-register with the WSUS Server. This seems to resolve the issue.
Option Explicit
Dim strRegKey, WshShell, strServiceName
Set WshShell = WScript.CreateObject("WScript.Shell")
'Delete Automatic Update Client ID
strRegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\" _
& "CurrentVersion\WindowsUpdate\SusClientId"
WshShell.RegDelete strRegKey
'Restart Automatic Update Windows Service
strServiceName = "wuauserv"
WshShell.Run "Net Stop " & strServiceName, 0, True
WshShell.Run "Net Start " & strServiceName, 0, True
'Force the Client to report to the WSUS Server
WshShell.Run "wuauclt.exe /detectnow /resetauthorization"
We did a little reading and found this by Stephen Farrar. It appears that the Sysprep process that we used to commission our VMs on ESX does not strip out the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId] entry in the Registry and therefore all of our VMs have the same ID.
I've written a VBScript which first of all deletes the key, stops and starts the Automatic Updates service and then forces the client to re-register with the WSUS Server. This seems to resolve the issue.
Option Explicit
Dim strRegKey, WshShell, strServiceName
Set WshShell = WScript.CreateObject("WScript.Shell")
'Delete Automatic Update Client ID
strRegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\" _
& "CurrentVersion\WindowsUpdate\SusClientId"
WshShell.RegDelete strRegKey
'Restart Automatic Update Windows Service
strServiceName = "wuauserv"
WshShell.Run "Net Stop " & strServiceName, 0, True
WshShell.Run "Net Start " & strServiceName, 0, True
'Force the Client to report to the WSUS Server
WshShell.Run "wuauclt.exe /detectnow /resetauthorization"
29 Apr 2009
Custom HTTP Protocol Issue in ISA Server 2006
While trying to publish a CRL (Certificate Revocation List) Location through two sets of MS ISA 2006 Arrays, we had an issue with the HTTP Protocol in ISA proxying the request and therefore changing the Source IP of the request to the ISA rather than the original requesting server's IP.
To remedy this, we created a new HTTP Protocol in ISA and removed the Web Proxy filter from the new protocol. The new protocol was then used in the access rules.
This seemed to go some way to resolving the issue although we still had problems, as it appeared that the out of box HTTP Protocol was still being used and consequently the rule in the next set of ISAs in the route was not matching.
We stumbled across the link below which described our problem which involves creating a deny rule after the problematic access rule. This worked even though the guys commenting on the blog below state that they had problems with it on ISA 2006.
Check the MS ISA Team blog here
To remedy this, we created a new HTTP Protocol in ISA and removed the Web Proxy filter from the new protocol. The new protocol was then used in the access rules.
This seemed to go some way to resolving the issue although we still had problems, as it appeared that the out of box HTTP Protocol was still being used and consequently the rule in the next set of ISAs in the route was not matching.
We stumbled across the link below which described our problem which involves creating a deny rule after the problematic access rule. This worked even though the guys commenting on the blog below state that they had problems with it on ISA 2006.
Check the MS ISA Team blog here
Labels:
ISA Server 2006
9 Feb 2009
SCOM 2007 SCW Manifest
I'm in the process of implementing the Beta of SCOM 2007 R2 at work and had some SCW work to do on the servers that are going to run the SCOM Agents. I found this useful link which has the XML manifest for SCOM 2007, allowing easier configuration of the various SCOM 2007 components using the Security Configuration Wizard.
http://www.microsoft.com/downloads/details.aspx?FamilyID=244512ab-7419-4c93-8046-9c8e47e0f780&DisplayLang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=244512ab-7419-4c93-8046-9c8e47e0f780&DisplayLang=en
15 Jan 2009
SQL Server 2005 SPNs
When running SQL Server 2005 services under normal domain user accounts, there's some additional configuration that's needed to have SQL auto register it's SPN which is required for Kerberos authentication.
If SQL is unable to register an SPN upon startup you'll see "The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15." in the SQL Error logs. If the SPN can't be registered then the authentication will fall back to NTLM instead of Kerberos.
Step 3 in the following article describes the steps that i performed on the SQL Server service account to enable the self registration of the SPNs. - http://support.microsoft.com/kb/319723
The following TSQL can be ran from SSMS to determine the current authentication method (Kerberos or NTLM).
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
Also more info can be found here - http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
If SQL is unable to register an SPN upon startup you'll see "The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15." in the SQL Error logs. If the SPN can't be registered then the authentication will fall back to NTLM instead of Kerberos.
Step 3 in the following article describes the steps that i performed on the SQL Server service account to enable the self registration of the SPNs. - http://support.microsoft.com/kb/319723
The following TSQL can be ran from SSMS to determine the current authentication method (Kerberos or NTLM).
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
Also more info can be found here - http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
Labels:
Kerberos,
SPN,
SQL Server
22 Apr 2008
Cobbled together SBS 2000 - 2003 Swing Migration
I was involved in an SBS Migration for a friend of the family recently. It involved migrating from a custom chassis with SBS 2000 to a HP ML350 G5 running SBS 2003 Standard.
Before i attempted the migration i performed a ton of research, probably in the region of 20+ hours. I found information at the http://www.smallbizserver.net/ forum amongst other places. Although there are lots of recommendations for Jeff Middleton's Swing Kit (which is no doubt a good investment), i felt capable enough to perform the migration unaided once i believed i'd got the jist of the overall process.
Worth a read if you're unsure of the constraints regarding SBS and additional DCs in a domain (http://blogs.technet.com/sbs/archive/2007/10/04/debunking-the-myth-about-additional-domain-controllers-replica-dcs-in-an-sbs-domain.aspx)
The below points are purely a brain dump of the issues that i encountered and resolved throughout the migration. If you're feeling brave enough to try a Swing migration then they may assist. Use at own risk or consider Jeff's Swing Kit.
Before i attempted the migration i performed a ton of research, probably in the region of 20+ hours. I found information at the http://www.smallbizserver.net/ forum amongst other places. Although there are lots of recommendations for Jeff Middleton's Swing Kit (which is no doubt a good investment), i felt capable enough to perform the migration unaided once i believed i'd got the jist of the overall process.
Worth a read if you're unsure of the constraints regarding SBS and additional DCs in a domain (http://blogs.technet.com/sbs/archive/2007/10/04/debunking-the-myth-about-additional-domain-controllers-replica-dcs-in-an-sbs-domain.aspx)
The below points are purely a brain dump of the issues that i encountered and resolved throughout the migration. If you're feeling brave enough to try a Swing migration then they may assist. Use at own risk or consider Jeff's Swing Kit.
- On current server perform a full backup and Exmerge mailboxes
- Backup data to be transferred over and note Shares currently on the server along with their local paths (net share >shares.txt)
- Domain Prep and Forest Prep Current Domain to 2003 Schema
- Build and join a VMware SBS Install to current domain
- On VMWare server install DNS
- DCPROMO VMWare server
- Tick Global Catalog box and wait for event 1119 (Confirmation of Global Catalog)
- Ensure AD and DNS has replicated, test by creating a user and check that details are replicated between servers.
- Disconnect VMware server from current server
- On VMWare server, Seize FSMO Server Roles - http://www.petri.co.il/seizing_fsmo_roles.htm
- Cleanse AD of old DC (AD and DNS) - http://support.microsoft.com/kb/216498. (To remove the DC from DNS i just scoured the zones for all references for the old server and deleted them)
- Build New physical server
- Add New server to Domain running on VMWare
- Install DNS on new physical server
- DCPROMO New server
- DC PROMO VMWare server
- Tick Global Catalog box and wait for event 1119 (Confirmation of Global Catalog)
- Ensure AD and DNS has replicated, test by creating a user and check that details are replicated between servers.
- Disconnect new server from VMWare server
- On new physical DC Seize FSMO Roles (See previous links)
- On new DC, cleanse AD and DNS of VMWare DC
- Fix Authoritative Time Server events due to the change in PDC role - http://support.microsoft.com/kb/816042
- Install the rest of SBS using the SBS Setup (Exclude Exchange)
- Forest Prep and Domain prep in preparation for the updated Exchange install (2000 - 2003)
- Perform Exchange Disaster recovery install (setup.exe /disasterrecovery) Necessary due to entries for the previous server still being present in the Exchange Org and two servers with the same name can't co-exist regardless of whether one of them being offline.
- Install Exchange Service Pack(s).
- Install Exchange System Manager as this isn't installed as part of the DR Install. (I found this helpful)
- Test Exchange services but a permission change is required for the Exchange computer account to be able to modify the Exchange portion of the schema. (http://support.microsoft.com/default.aspx?scid=kb;en-us;325674)
- Forklift Exchange Database to new server or Recreate mailboxes and exmerge in from previously created PSTs - More clues can be found here for the forklifting exchange databases.
- The IUSR_%SERVERNAME% user account password may need changing to ensure that IIS sites relying on Anonymous access such as OWA work correctly due to the mismatch in passwords between the user account and the IIS metabase (Find out how to sync them here)
- Copy over data and recreate shares with correct permissions
- Some notes on a Fax service install are here regarding some permission issues when moving from 2000 - 2003 (http://support.microsoft.com/kb/842207)
I'll update and correct this once I've had a good think. This is designed purely as a list of pointers and not a full migration guide.
Subscribe to:
Posts (Atom)