GAPTHEGURU

Geek with special skills

How to setup Active Directory Federation Services

Part 1

Active directory federation service is Windows component which enables authentication of users on sites beyond its administrative domain. Example for this type of authentication is when users from one site have to access resources on some external site such as resources in partner network (e.g. Partner web sites etc.) When resource on remote site needs authentication for accessing, but “local” credentials should to be used, that is point where Active Directory Federation Service (AD FS) takes place.

Active Directory Federation Services enable using your AD (Active Directory) service to authenticate its users when they access resources belonging to other domains and placed on remote locations. To enable service which allows this type of authentication Active Directory federation should de established between two remote sites. There should be Active Directory Federation servers placed on both locations.

User authentication on site where resources reside and where user tries to access are based on token issued by federation services server on user location. Next picture shows AD FS architecture:

On user side, where Account Federation server resides is AD controller which authenticates users. On remote location in resources site is Resource Federation Server which participate in user authentication on remote site.

Follow scenario happens when user tries to access recourse on remote side:

1. User send request to access resource

2. Application server(SharePoint on picture) contacts Resource Federation server to authenticate user

3. Resource Federation server claim Account Federation server providing user identities

4. Account Federation server send user identities to Active Directory which authenticates user

5. Account Federation server creates token for user and send it to Resource federation server

6. When receive token for user Receive Federation server creates service token and forward it to resource server (SharePoint) and authentication process is completed.

On described way is provided SSO (single sign on) mechanism for users accessing resources on locations which are out of its administration boundary. Trust between two organizations is established though Active Directory Federation services.

To establish federation between two sites a few steps should be performed:

– Installation AD Federation Services on Account and Resource Federation servers

– Configuration of resource server(web server or other application server to which resources clients access)

– Configuration of Federation Servers(both account and resource) to establish trusted relationships

–  Client configuration

Installation AD Federation Services on Account and Resource Federation servers

AD FS services can be installed as role on Windows Server 2008. To begin installation go to Start->Administrative Tools->Server Manager. Then right click on roles and Add Role. Opens Add roles wizard:

Click on Active Directory Federation Services and then Next. Next window is Role Services. Click on check box by component you want to install (in this case Federation Service):

Maybe you will be prompted to install additional services such as IIS or some components of IIS needed for AD FS working. Confirm installation additional services (click on Add Required Role Services). When installation finishes click Next. Window for choosing SSL certificate for AD FS server appears. This certificate will be used for securing communication between clients and federation server.

As certificate for SSL connection you can choose existing certificate issued by your enterprise CA authority or create self signed certificate created on federation server. In this example self signed certificate will be used. For that click Create a self-signed certificate for SSL encryption and click Next. Opens window for token signing certificate:

Token signing certificate is used for signing tokens issued for client authentication on remote site where are resources which client want to access. When client make request to access resources application server (SharePoint on picture) request Resource Federation server to identify client. Resource Federation Server then contacts Account Federation Server on client side. When request for client authentication comes to Account Federation Server this server contacts AD controller which authenticates client. After client authentication  by AD is finished, Account Federation Server generates token signed by Token-Signing Certificate and sent it to Resource Federation Server which then generates service token and send it to resource server. When this process is completed client can access resources.

After Token-signing certificate is generated click next. Appears window for trust policy generation:

Trust policy defines rules applied when request from partner Federation Server comes to authenticate user. It defines situations in request should be accept or denied and types of information should be included in token issued to Federation Server on the side of partner organization. Trust policy can be created for this purpose or existing can be used. In this example we will create new policy. Click on Create new policy and then Next. Appears window with list of services which will be installed:

In this case AD Federation service and IIS server will be installed.

When verify which services will be installed click Install to begin installation process. After finishing window which shows results of installation is displayed:

With this last step AD FS server role is installed. On the same way this role installs on both Recourse and Account Federation server. After installing AD FC roles servers should be properly configured for trust relationship and communication establishing. Also resource server should be configured to be aware of federation server.

PART 2

When you have Federation Services installed as server roles on both sides of federation (account and resource) you have to properly configure servers to establish trust between them. Configuration includes configuring trust policy on both servers, create and configure group claim and AD account store and establish trust by importing policy from one federation server to another, on partner side. In this article I will describe process of AD FS server configuration. Configuration of both federation servers (account and resource) will be described.

Configuring Federation Services on federation servers

 Trust policy configuration

First thing to configure is trust policy configuration. To do that go through next steps:

1. Open AD FS configuration console. Go to Start->Administrative Tools and click Active Directory Federation Services. Opens next window:

2. On console tree double click Federation Services and then right click on Trust Policy and then Properties:

3. On General tab in Federation Services URI type URI of AD Federation Service. This URI is used to identify federation service on federation server. If AD FS is installed on server farm this URI should be same for all servers in farm. Also, in partner organization this URI should be same in trust policy imported from partner.

4. In the Federation Service endpoint URL text box URL of federation service appear. There is default URL, you can change it.

5. On Display Name tab type trust policy name and click OK.

On the same way trust policy should be configured on both federation servers, with differences in policy names, URLs and AD FS URIs.

Create group claim for claim-aware application

1. For authentication requests from partner side to be handled group claim should be created. To create group claim Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Organization Claims, go to New and click Organization Claim

3. In the Create a New Organization Claim dialog box in Claim name type name of new organization claim. It is claim from AD FS service on other (partner) side, let say Partner Claim.

4. Ensure that Group claim is selected and click OK

Claim should be configured on both sides, Account Federation server and Resource Federation Server

Add AD account store

When group claim is created and configured account store should be added. It is store in which are placed user credentials authenticated during resource accessing . In this case Active Directory will be used as account store. AD is most efficient and most used store for users when AD FS services are used.

To add AD as account store do next steps:

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Account Stores, go to New and click Account Store:

3. On the Welcome to the Add Account Store Wizard page, click Next.

4. On the Account Store Page Active Directory Domain Services should be selected. Click Next

5. Enable this Account Store page appears. Enable this account store check box should be selected. Click Next

6.  On the Completing the Add Account Store Wizard page, click Finish

Adding account store in configuring AD FS server should be performed on both federation servers (Account and Resource)

Map a global group to the group claim for claims aware application

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization , double click Account Stores, right click Active Directory, go to New and click Group Claim Extraction.

3. In Create a New Group Claim Extraction dialog box, click Add, type name of your mapping, for example partnerclaimusers, and then click OK.

4. Map to this Organization Claim menu should display group claim for partner organization, in this case Partner Claim we configured earlier. Click OK

Mapping a global group to the group claim should be configuring only on account federation server side because user that accessing resources are on that side, in same domain as account AD FS server. On this side of resource federation server claims aware application should be added and configured.

Adding and configuring claims aware application on AD FS of resource federation server

When configuring account federation server map group claim to group of users in AD is needed. On the other side, on resource federation server mapping of claims aware application should be done to connect application to which clients access with federation service. To add claim aware application do next steps on Resource Federation server:

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Application, go to New and click Application.

3. On the Welcome to the Add Application Wizard page, click Next

4. On the Application Type page, click Claims-aware application, and then click Next.

5. On the Application Details page, in Application Display Name, type Claims-aware Application

6. In application URL type URL of your web application to which client access (e.g. http://web.domain.com/application

7. On the Accepted Identity Claims page, click User principal name (UPN), and then click Next.

8. On the Enable this application page check Enable this application and click Next

9. Click finish on Completing the Add Application Wizard page

After adding claims aware application group claim should be added to application. For this go to Applications folder, click to Claims aware application, right click to your group claim and click Enable.

When described settings are done federation servers are configured for federation but for establishing full trust between servers exporting and importing trust policies between servers is needed. When policies are exchanged trust between servers is established and AD FS service is configured between organizations.

Advertisements

05/23/2012 Posted by | Active Directory, ADFS, Federation, Security, SSO, Windows Server | , , | 1 Comment

Microsoft Forefront TMG and UAG – A feature comparison

Let’s begin

First of all let’s have a brief description about Forefront TMG and Forefront UAG.
Forefront TMG

Forefront Threat Management Gateway 2010 (TMG) is the successor of ISA Server 2006. For a detailed comparison between ISA Server 2006 and Forefront TMG read the following article. Forefront TMG is a Multilayer Enterprise Firewall with several features:

  • Stateful Packet filtering
  • Application Layer Firewalling
  • HTTP Filter
  • HTTPS Inspection
  • URL Filtering
  • Malware Inspection
  • VPN Server (Client VPN and Site to Site VPN)
  • Web proxy and Web caching Server
  • Forward- and reverse Proxy
  • E-Mail Protection Gateway
  • Intrusion Prevention (IPS) and Intrusion Detection (IDS) system

Forefront TMG is available in two versions: Standard and Enterprise. For an overview about the Forefront TMG editions read the following article.

System requirements for Forefront TMG:

Component

Minimum requirements

CPU 64-bit, 1.86 GHz, 2 core (1 CPU x dual core) processor
Memory 2 GB, 1 GHz RAM
Hard Disk 2.5 GB available space. This is exclusive of the hard disk space required for caching or for temporarily storing files during malware inspection. One local hard disk partition that is formatted with the NTFS file system
Network adapters One network adapter that is compatible with the computer’s operating system, for communication with the Internal network
Operating system Windows Server 2008Version: SP2 or R2
Edition: Standard, Enterprise or Datacenter
Windows Roles and Features These Roles and Features are installed by the Forefront TMG Preparation Tool:
Network Policy ServerRouting and Remote Access Services

Active Directory Lightweight Directory Services Tools

Network Load Balancing Tools

Windows PowerShell

Other software Microsoft .NET Framework 3.5 SP1Windows Web Services API

Windows Update

Microsoft Windows Installer 4.5

Table 1

Forefront UAG

Forefront Unified Access Gateway 2010 (UAG) is the successor of Microsoft IAG (Intelligent Application Gateway) and is designed to control inbound access to corporate resources from several client types such as, Windows, Linux, and Macintosh clients, including mobile devices. One of the major strengths of Forefront UAG is the so called Endpoint access policy which can be used to give clients access to internal resources only when a predefined set of rules, defined by UAG administrators are satisfied. You can think about Forefront UAG Endpoint access Policies as an enhanced version of NAP (Network Access Protection). Forefront UAG enhances the basic Webserver publishing options found in Forefront TMG by integrating a deep understanding of the applications published, the state of health of devices being used to gain access, and the user’s identity.

Forefront UAG provides portal support for gaining access to internal resources. A portal is a website where users can gain access to different published applications like OWA, Remote Desktop connections, SSL VPN, Microsoft CRM, SharePoint and many others.

Forefront UAG supports several authentication providers like Active Directory, Netscape, LDAP, RADIUS, OTP and many more. Another primary development goal of Forefront UAG is remote access via SSL VPN and a technique called DirectAccess.

System requirements for Forefront UAG:

 

Component

Minimum requirements

CPU 2.66 gigahertz (GHz) or faster processor. Dual core CPU
Memory 4 GB
Hard Disk 2.5 gigabyte (GB) (in addition to Windows requirements)
Network adapters Two network adapters that are compatible with the computer operating system. These network adapters are used for communication with the internal corporate network, and the external network (Internet). Note that deploying Forefront UAG with a single network adapter is not supported
Operating system Forefront UAG can be installed on computers running the Windows Server 2008 R2 Standard or Windows Server 2008 R2 Enterprise 64-bit operating systems. Forefront UAG must be a domain member
Windows Roles and Features Network Policy ServerRouting and Remote Access Services

Active Directory Lightweight Directory Services Tools

Message Queuing Services

Web Server (IIS) Tools

Network Load Balancing Tools

Windows PowerShell

Other software Microsoft .NET Framework 3.5 SP1Windows Web Services API

Windows Update

Microsoft Windows Installer 4.5

SQL Server Express 2005

Forefront TMG is installed as a firewall during Forefront UAG setup. Following setup, Forefront TMG is configured to protect the Forefront UAG server.

The Windows Server 2008 R2 DirectAccess component is automatically installed

Table 2

Comparing Forefront TMG and Forefront UAG

During my work as a Consultant and Trainer for Forefront products, I noticed that many customers were not completely aware of the main differences between Forefront TMG and UAG and were uncertain which product best fits a given scenario.

I will try to give a short description of each product that helps you take the right decision:

Forefront TMG is the Enterprise Edge Firewall that protects the internal network from the Internet and that provides protected access from internal resources to the Internet. Forefront TMG has powerful publishing features to publish internal services to the Internet such as, Outlook Web Access, Exchange Active Sync and a whole slew of other services, but it is limited in intelligent publishing. It only allows limited control on client devices which should access the internal published resources. In fact, Forefront TMG acts as a Firewall for incoming and outgoing requests.

Forefront UAG is used to extend and enhance the basic publishing features of Forefront UAG, and comes with extended features like portals, SSL VPN (note: Forefront TMG supports SSL VPN in form of SSTP), DirectAccess and powerful Endpoint Access Policies to control the client devices, accessing the Forefront UAG server. During a Forefront UAG installation, Forefront TMG will also be installed but only to protect the Forefront UAG Server. In fact, Forefront UAG acts as an Application Layer Gateway and is the solution for incoming access to internal resources from the Internet.

The following screenshot gives a clear explanation about Forefront TMG and Forefront UAG usage scenarios:


Figure 1: Forefront TMG and Forefront UAG comparison (Source: Microsoft)

Forefront TMG unsupported configurations

advertisement

 

As with every solution there are supported and unsupported configurations. The unsupported configurations with Forefront TMG are:

  • Forefront TMG is not supported on a 32-bit operating system
    – Forefront TMG can only be installed on a 64 Bit Operating system (2008 SP2 and 2008 R2)
  • Forefront TMG is not supported on Windows Server 2003
  • Forefront TMG is not supported on all editions of Windows Server 2008
    – Installation of Forefront TMG is only supported in Standard, Enterprise and Datacenter Edition and is not supported on Windows Server Core!
  • Installing EMS on a Forefront TMG computer is not supported
    – EMS is the Enterprise Management Server (formerly known as CSS)
  • In-place upgrade from ISA Server 2004/2006 to Forefront TMG is not supported
    – You have to export the ISA Server configuration and to import this configuration on a fresh TMG installation
  • In-place upgrade from Windows Server 2008 SP2 to Windows Server 2008 R2 is not supported
    – Forefront TMG does not support upgrading to Windows 2008 R2 while Forefront TMG is installed.
  • Forefront TMG installed on a domain controller is not supported, except with Forefront TMG SP1 where the installation of TMG is allowed on a Read Only Domain Controller (RODC)
  • Forefront TMG Client is not supported on Windows 2000
  • Forefront TMG does not support Firewall Client 2000
  • Workgroup deployment limitations
    – user group authentication only with the use of LDAP (for publishing scenarios) or RADIUS (for in and outgoing access)
    – Client certificates cannot be used as primary authentication
    – User mapping is not supported (except for PAP and SPAP)
    – Group policy deployment of certificates for HTTPS inspection is not available
    – Automatic Web proxy detection using Active Directory Auto Discover is not possible.
  • Multiple firewalls products
    – Installing other firewall products (such as a personal firewall) on a Forefront TMG Server is not supported

Forefront UAG support boundaries

Forefront UAG has some supported and unsupported configurations. The support boundaries are:

Forefront UAG and Forefront UAG DirectAccess

Forefront UAG can be used to publish internal servers via Web portal or directly (similar to Forefront TMG).

Forefront UAG can be used as a DirectAccess Server to extend the DirectAccess functionality which comes with Windows Server 2008 R2. Please, note the following:

  • Forefront UAG can be configured as a publishing Server and as a DirectAccess Server on the same machine.
  • Servers in a Forefront UAG Array can be configured to provide remote access to published servers and as a DirectAcccess server at the same time.
  • It is not possible to use the Network Connector application (a form of VPN) when Forefront UAG is configured as a DirectAccess server.

IPv6 support

In order to support DirectAccess which is IPv6-based, Forefront UAG allows the following IPv6 traffic:

  • Inbound authenticated IPv6 traffic (using IPsec).
  • Native IPv6 traffic from and to the Forefront UAG DirectAccess server.
  • Inbound and outbound IPv6 transition technologies (6to4, Teredo, IP-HTTPS and ISATAP).

No other IPv6 traffic is supported by Forefront UAG.

Forefront TMG running on Forefront UAG

A frequent misunderstanding is the role of Forefront TMG with Forefront UAG. I have spoken with many customers in the past, who wanted to replace their Forefront TMG servers with Forefront UAG to benefit from the Forefront UAG features. But Microsoft has clear statements about supported and unsupported configurations, which are:

  • Forefront TMG is installed during a Forefront UAG installation.
  • Forefront TMG is installed as a complete product, and is not modified to run on a Forefront UAG server.
  • Forefront UAG uses Forefront TMG, as follows:
  • Forefront TMG acts as a firewall, protecting only the Forefront UAG server.
  • Forefront UAG uses Forefront TMG infrastructure and functionality in some deployment and monitoring scenarios.
  • Changes made through the Forefront UAG console are pushed to the Forefront TMG configuration and only in this way!

It is possible to configure some parts of Forefront TMG through the Forefront TMG Management console (MMC), but the following is not supported:

  • Forefront TMG will be automatically installed during a Forefront UAG installation, a manual Forefront TMG installation is not supported.
  • Forefront UAG must be installed on a clean Windows Server 2008 SP2/R2 machine without Forefront TMG installed.
  • Forefront TMG will be removed if you remove Forefront UAG.
  • A manual uninstallation of Forefront TMG is not supported.
  • Forefront TMG as a forward proxy for outbound Internet access.
  • Forefront TMG as a site-to-site VPN server.
  • Forefront TMG as an intrusion protection system.
  • Publishing Forefront TMG via Forefront UAG.

Supported Forefront TMG configurations

You can use the Forefront TMG Management console (MMC) for the following configurations:

  • Creating access rules to limit access for users, groups, and networks for VPN remote access. These access rules must be placed under the automatically created Firewall policies from Forefront UAG.
  • Monitoring, logging and reporting.
  • Modifying Forefront TMG system policies to enable access from Forefront TMG to internal Servers and to give access from internal Servers to Forefront TMG.
  • Publish Exchange SMTP/SMTPS.
  • Publish Exchange IMAP/IMAPS.
  • Publish Exchange POP3/POP3S.
  • Publish Office Communications Server (OCS) (with the exception of the OCS web access which should be published with Forefront UAG).

Forefront UAG placement

Because of the several limitations you must plan where to implement the Forefront UAG in your network environment. Possible placements are:

  • Forefront UAG in a DMZ (Perimeter) scenario with a Front- and Back firewall in place.
  • Forefront UAG as a parallel placement with your existing Firewall.

You might need to open several Firewall ports for correct communications with Forefront UAG. You will find more information about these deployments here.

Conclusion

In this article, I went through a detailed comparison between Forefront TMG and Forefront UAG features, and discussed the support boundaries of Forefront UAG and unsupported configurations of Forefront TMG. I hope that this article helps you to decide which version is the right one for your deployment.

04/27/2012 Posted by | Security, TMG, UAG | , | 8 Comments

BIZTALK: How to Cluster the Master Secret Server

The last few weeks I have been setting up a new Biztalk environment with the Biztalk databases on a MS SQL 2008 R2 SP1 failover cluster. In my last post i showed how to cluster the MSMQ and MSDTC and here is my way to cluster the Master Secret Server. When you cluster the master secret server, the Single Sign-On servers communicate with the active clustered instance of the master secret server. Similarly, the active clustered instance of the master secret server communicates with the SSO database.

To install and configure Enterprise SSO on the cluster nodes (Windows Server 2008)

  1. Install BizTalk Server 2010 on each cluster node. In the Component Installation dialog box of the Microsoft BizTalk Server Installation Wizard, select to install the Enterprise Single Sign-On Administration Module and Enterprise Single Sign-On Master Secret Server components. After installation has completed successfully you have the option to run the BizTalk Server 2010 Configuration program but do not do so at this time.
  2. Create domain groups with the names SSO Administrators and SSO Affiliate Administrators. To create a clustered instance of the Enterprise SSO service, you must create the SSO Administrators and SSO Affiliate Administrators groups as domain groups.
  3. Create or designate a domain account that is a member of the SSO Administrators domain group. The Enterprise SSO service on each node will be configured to log on as this domain account. This account must have the Log on as a service right on each node in the cluster.
  4. Add the account that you are using to log on during the configuration process to the domain SSO Administrators group.
  5. Start the BizTalk Server 2010 Configuration program. Click Start, point to Programs, point to Microsoft BizTalk Server 2010, and then click BizTalk Server Configuration to display the Microsoft BizTalk Server 2010 Configuration dialog box.
  6. Choose the Custom Configuration option and enter the appropriate values for the Database server name, User name and Password fields. After entering these values click the Configure button to continue.
  7. Select the Enterprise SSOoption from the left pane of the Microsoft BizTalk Server 2010 Configuration dialog box and set the following options for the Enterprise SSO feature:
    1. Select the check the box next to Enable Enterprise Single Sign-On on this computer.
    2. Click the option to Create a new SSO system.
    3. Enter the appropriate values under Data stores for Server Name and Database Name.
    4. Verify that the domain account that you created earlier is the account that is associated with the Enterprise SSO service.
    5. Specify the domain SSO Administrators group that you created earlier as the group associated with the SSO Administrator(s) role.
    6. Specify the domain SSO Affiliate Administrators group that you created earlier as the group associated with the SSO Affiliate Administrator(s) role.
  8. Select the Enterprise SSO Secret Backup option from the left pane of the Microsoft BizTalk Server 2010 Configuration dialog box and provide the appropriate parameters for backing up the Enterprise SSO secret. By default the Enterprise SSO secret is backed up to <drive>:\Program Files\Common Files\Enterprise Single Sign-On\SSOxxxx.bak.
  9. Click the Apply Configuration option to display the Microsoft BizTalk Server 2010 Configuration Wizard Summary dialog box.
  10. Click Next to apply the configuration.
  11. Click Finish to close the Microsoft BizTalk Server 2010 Configuration Wizard.
  12. Close the Microsoft BizTalk Server 2010 Configuration program.
  13. Log on to the passive cluster node and start the BizTalk Server 2010 Configuration program.
  14. Choose the Custom Configuration option and enter the same values for the Database server name, User name, and Password fields that you entered when configuring the first cluster node. After entering these values click the Configure button to continue.
  15. Select the Enterprise SSOoption from the left pane of the Microsoft BizTalk Server 2010 Configuration dialog box and set the following options for the Enterprise SSO feature:
    1. Check the box next to Enable Enterprise Single Sign-On on this computer.
    2. Click the option to Join an existing SSO system.
    3. Enter the same values for the SSO Database Server Name and Database Name that you entered when configuring the first cluster node.
    4. Enter the same value for the domain account that you entered when configuring the first cluster node.
  16. Click the Apply Configuration option to display the Microsoft BizTalk Server 2010 Configuration Wizard Summary dialog box.
  17. Click Next to apply the configuration.
  18. Click Finish to close the Microsoft BizTalk Server 2010 Configuration Wizard.
  19. Close the Microsoft BizTalk Server 2010 Configuration program.

To update the master secret server name in the SSO database

  1. Type the following commands from a command prompt on the active cluster node to stop and restart the Enterprise SSO service:
  1. net stop entsso

and

net start entsso

  1. Change the master secret server name in the SSO database to the cluster name by following these steps:
Note
The cluster name is the name defined for the network name resource that you have created in the cluster group / clustered service or application that will contain the clustered Enterprise SSO service. For example, the name may be BIZTALKCLUSTER.
    1. Paste the following code in a text editor:
  1. <sso>
  2.   <globalInfo>
  3.     <secretServer>BIZTALKCLUSTER</secretServer>
  4.   </globalInfo>
  5. </sso>
Note
BIZTALKCLUSTER is a placeholder for the actual network name resource that is created in the cluster group / clustered service or application.
    1. Save the file as an .xml file. For example, save the file as SSOCLUSTER.xml.
    2. At a command prompt, change to the Enterprise SSO installation folder. By default, the installation folder is <drive>:\Program Files\Common Files\Enterprise Single Sign-On.
    3. Type the following command at the command prompt to update the master secret server name in the database:

10.ssomanage -updatedb XMLFile

Note
XMLFile is a placeholder for the name of the .xml file that you saved earlier.

To create the clustered Enterprise SSO resource (Windows Server 2008)

  1. If the cluster is not configured with a clustered Distributed Transaction Coordinator (MSDTC) resource then follow the steps in my last post.
  2. Click Start, Programs, Administrative Tools, and then Failover Cluster Management to start the Failover Cluster Management program.
  3. In the left hand pane, right-click Failover Cluster Management and click Manage a Cluster.
  4. On the Select a cluster to manage dialog box, enter the cluster to be managed and click OK.
  5. In the left hand pane click to select a clustered service or application that contains an IP Address and Network Name resource.
Note
A clustered Enterprise SSO service does not explicitly require the use of a clustered Physical Disk resource in the same group.
  1. Right-click the clustered service or application, point to Add a resource, and click Generic Service to display the New Resource Wizard dialog.
Important
In the Generic Service Parameters dialog box, if you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service:

Failed to retrieve master secrets.

Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.

  1. On the Select Service page of the New Resource Wizard, click to select Enterprise Single Sign-On Service and click Next.
  2. On the Confirmation page click Next.
  3. On the Summary page click Finish. A clustered instance of the Enterprise Single Sign-On Service will appear under Other Resources in the center pane of the Failover Cluster Management interface.
  4. Right-click the clustered instance of the Enterprise Single Sign-On Service and select Properties to display the Enterprise Single Sign-On Service Properties dialog box.
  5. Click the Dependencies tab of the properties dialog box and click Insert.
  6. Click the drop down box under Resource, select the Name: resource and click OK.

To restore the master secret on the second cluster node (Windows Server 2008)

  1. In Failover Cluster Management, right click the clustered service or application that contains the clustered Enterprise Single Sign-On service and then click Bring this service or application online to start all of the resources in the clustered service or application.
  2. Right-click the clustered service or application, point to Move this service or application to another node, and click the second node. This step moves the clustered service or application that contains the clustered Enterprise Single Sign-On service from the first node to the second node.
  3. Right-click the clustered Enterprise Single Sign-On service and click Take this service or application offline, then right-click the clustered instance of the Enterprise SSO service and click Bring this service or application online.
Note
If this step is not completed the attempt to restore the master secret may not succeed.
  1. Copy the master secret backup file from the first node to the \Enterprise Single Sign-On installation folder on the second node. By default, the installation folder is <drive>:\Program Files\Common Files\Enterprise Single Sign-On.
  2. Log on to the second node and at a command prompt, change to the Enterprise SSO installation folder.
  3. Type the following command from the command prompt to restore the master secret to the second node:
  1. ssoconfig -restoresecret RestoreFile
Note
Replace RestoreFile with the path of and the name of the backup file that contains the master secret.
  1. The master secret is stored in the registry at the following location:
  2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ENTSSO\SSOSS
  3. Move the clustered service or application that contains the clustered Enterprise Single Sign-On service from this cluster node to other cluster node to ensure failover functionality. Then move the cluster group back to verify fail-back functionality.

 

03/12/2012 Posted by | Biztalk, SQL Scripting, Sql Server, SSO, T-SQL | , , , , | 1 Comment

Installation of SSO on SQL Failover Cluster

In this post I will tell a story of my experience with installation of SSO on SQL Cluster. Each BizTalk Server has an Enterprise Single Sign-On service (EntSSO.exe). Enterprise Single Sign-On is also referred as SSO or EntSSO. SSO serves two purposes. One is for data encryption, that is, port URI data. And the other is, as what the name indicates, Single Sign-On. Single Sign-On is about credential mapping. BizTalk Server SSO currently supports only Windows-initiated Single Sign-On. That means you can only map Windows users accounts to external application (affiliate application) user accounts. On the inbound side the sender is authenticated with Windows; on the outbound side, BizTalk Server automatically authenticates with the affiliate applications using the preconfigured credential mapping. Single Sign-On is a useful feature in business-to-business (B2B) scenarios.

Note: However the encryption function is mandatory for a BizTalk system. Single Sign-On for credential mapping can be solved with other tools like Oracle Wallet.

In addition to the SSO services running on each of the BizTalk Servers, there is a master secret server. The master secret server is a server with the SSO service running on it. The master secret server can be one of the SSO services running on one of the BizTalk Servers, or a dedicated master secret server.

It is the same executable called EntSSO.exe, but with an additional sub component responsible for maintain and supply the master secret key to the SSO services on the other BizTalk Servers. The other SSO services running on the BizTalk Servers check every 30 seconds to see whether the master secret has changed. If it has changed, they read it securely; otherwise, they continue to use the master secret they already have cached in memory.

Considering there is only one master secret server in your entire environment and the dependency of BizTalk Server, it is recommended that you use an active-passive cluster configuration for the master secret server. Because the master secret server doesn’t consume a lot of resources, it is very common to use the SQL Server failover cluster for clustering the master secret server.

On the first server cluster node where you run BizTalk Server Configuration, you choose to create a new SSO system. That makes the cluster node as the master secret server. The host name of the master secret server is the host name of the physical cluster node. The master secret key is automatically generated on that node. On the other cluster node, you choose to join the existing SSO system. To cluster the master secret server, you need to change the master secret server from the first cluster node host name to the virtual SQL Server failover cluster network name (NameSQL1), and create a SSO generic service cluster resource. At the end, you restore the master secret key to the other cluster nodes. So, when the cluster fails over to another node, that node has the master secret. These steps can be done using the domain admin account (usually a network senior administrator will perform these steps with this account i.e. as example I will name the account InstallBizTalk).

Clustering the master secret server service is a complicated process. You might find it confusing when and where you need to perform a step, and the order of the steps. Here are some general rules:

· You must install and configure SSO on each of the cluster nodes. When you create the new SSO system on the first cluster node, this node can be either an active cluster node or a passive cluster node.

· After you successfully installed and configured SSO on all of the cluster nodes, you must update the master secret server host name from a physical cluster node host name to the virtual cluster network name, and you must change the rename from an active node.

· After the master secret server host name is changed, you must restart the SSO service on the active node to refresh the cache by taking the SSO cluster resource offline and then online.

· You must create an SSO cluster resource before restoring the master secret key on the other cluster nodes.

· Before you restore the master secret key on a cluster node, you must make it the active node first.

Steps involved to successfully install and configure SSO on cluster will be outlined here.

There are several SSO user groups. Two of them are required when configuring the master secret server. SSO Administrators have the highest level user rights in the SSO system; and SSO Affiliate Administrators defines the affiliate applications that the SSO system contains.

To create a domain group account for the SQL Server service groups

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A using domain admin account.

2. Click Start, and then click Run.

3. In the Run dialog box, enter dsa.msc, and then click OK.

4. From Active Directory Users and Computers, if the YourDomain domain is not already expanded, click the plus sign (+) to expand the YourDomain.com domain.

5. In the left pane, right-click Users, point to New, and then click Group.

6. From New Object – Group, enter the following values, and then click OK.

Name Value
Group name SSO Administrators
Group scope Global
Group type Security

7. Repeat steps 5 to 6 to create one more group:

Name Value
Group name SSO Affiliate Administrators
Group scope Global
Group type Security

To create a domain user account for the SSO Service

1. (continue from the previous procedure)

2. In the left pane, right-click Users, point to New, and then click User.

3. From New Object – User, enter the following values, and then click Next.

Name Value
First name SSO
Last name Service
User logon name SSOService

4. Enter or select the following values, and then click Next.

Name Value
Password TBD
Confirm password TBD
User must change password at next logon (clear)
User cannot change password (select)
Password never expires (select)
Account is disabled (clear)

5. Click Finish.

Both YourDomain\SSOSerivce and domain admin account need to be members of the YourDomain\SSO Administrators group. It is designated for installing and configuring the BizTalk Server system.

To make YourDomain\SSOService and domain admin account members of SSO Administrators

1. (continue from the previous procedure)

2. In the left pane, highlight Users.

3. In the right pane, right-click SSO Service, point to All Tasks, and then click Add to a group.

4. From Select Group, enter or select the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain
Enter the object name to select SSO administrators

5. To acknowledge that the account was created, click OK.

6. Repeat steps 3 to 5 to add domain admin account into the same group.

Granting YourDomain\SSO Administrators Full Control on Cluster Node A

You need to grant YourDomain\SSOService or YourDomain\SSO Administrators with the full control privilege on the cluster administrator.

To grant YourDomain\SSO Administrators full control on the cluster

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A as YourDomain\IInstallBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, in the left pane, right-click CLUSTER NODE A, and then click Properties.

4. From CLUSTER NODE A Properties, click the Security tab, and then click Add.

5. From Select Users, Computers, or Groups, enter the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain.com
Enter the object name to select SSO administrators

6. Verify the Allow box is selected, and then click OK.

Installing the SSO Components on Cluster Node A

With the accounts and permissions configured in the last step, you can now install the master secret server. BizTalk Server is not cluster aware as SQL Server is. You will need to install SSO on each of the cluster nodes. You will also need to create the SSO cluster resource manually.

BizTalk Server installation process has two parts. In this step, you will install the components. And the next step is configuring the master secret server.

To install the SSO components on Cluster Node A and Cluster Node B

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Run setup.exe to install BizTalk Server 2006 R2.

3. On the Start page, click Install Microsoft BizTalk Server 2006 R2 on this computer.

4. On the Customer Information page, enter information in the User name box, the Organization box, and the Product key box, and then click Next.

5. On the License Agreement page, read the license agreement, select yes, I accept the terms of the license agreement, and then click Next.

6. On the Component Installation page, clear all the check boxes, select Enterprise Single Sign-On Administration Module and Enterprise Single Sing-On Master Secret Server from the Additional Software group, and then click Next.

clip_image002

7. On the Summary page, click Install.

8. On the Installation Completed page, clear Launch BizTalk Server Configuration check box, and then click Finish.

Installing the SSO Components on Cluster Node B

Repeat the same steps to install the SSO components on Cluster Node B.

Configuring the Master Secret Server on Cluster Node A

Configuring the master secret server has three parts, creating SSO database, assigning SSO service account, and backing-up the master secret. Notice there are two options, create a new SSO system, and join an existing SSO system. On the first cluster nodes, you must choose to create a new SSO system. When you create a new SSO system, you must specify the database server name, and the database name. But you don’t need to specify the master secret server host name. The current host name, becomes the default master secret server. Later, you must change the master secret server from the physical cluster node host name to the virtual cluster host name, YourVirtualServerName.

It doesn’t matter whether Cluster Node A is the active node or a passive node when you go through this procedure.

To configure the master secret server on Cluster Node A

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name Database Name Cluster
User name YourDomain\SSOService
Password TBD

4. in the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Create a new SSO system (selected)
SSO Database: Server Name Database Name Cluster
SSO Database: Database Name SSODB
Enterprise Single Sign-On Service: Account YourDomain\SSOService
SSO Administrator(s): Windows Group YourDomain\SSO Administrators
SSO Affiliate Administrators(s): Windows Group YourDomain\SSO Affiliate Administrators

image

6. In the left pane, click Enterprise SSO Secret Backup. The Enterprise SSO secret is very critical. You must back it up to a file. It is a good practice to burn the key into a CD and store the CD in a safe place.

7. In the right pane, enter the following values:

Name Value
Secret back password TBD
Confirm password TBD
Password reminder TBD
Backup file location C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak)

8. Click Apply Configuration.

9. On the Summary page, to apply the configuration, click Next.

10. Verify that the Configuration Result is Success, and then click Finish.

11. Close Microsoft BizTalk Server 2006 Configuration.

1.1.4 Configuring SSO on Cluster Node B

On the second node, you choose to join the existing SSO system. When joining the existing SSO system, it shares the SSO database of the existing SSO system.

To configure the master secret server on Cluster Node B

1. If you haven’t logged on, log on to Cluster Node B as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name ServerName Database Cluster
User name YourDomainSSOService
Password TBD

4. In the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Join an existing SSO system (selected)
Server Name ServerName Database Cluster
Database Name SSODB
Account YourDomain\SSOService

6. Click Apply Configuration.

7. On the Summary page, to apply the configuration, click Next.

8. Verify that the Configuration Result is Success, and then click Finish.

9. Close Microsoft BizTalk Server 2006 Configuration.

1.1.5 Updating the Master Secret Server Host Name

When SSO was configured on the first cluster node, it created a new SSO system. It used the host name of the physical cluster node as the master secret server host name that is Cluster Node A. You must change it to the server cluster virtual name, which is YourVirtualClusterName. This procedure must be carried out from the active cluster node. All it does is to update the master secret server field in the SSO database.

To configure the master secret server on Cluster Node B

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

<sso>
  <globalInfo>
    <secretServer> ServerName Database Cluster</secretServer>
  </globalInfo>
</sso>

2. Open a notepad.exe, create a file with the following content, and then save it as “C:\Program Files\Common Files\Enterprise Single Sign-On\SSOCluster.xml” (with the double quotes). The content is case sensitive.

clip_image002[5]

3. Open a command prompt, and then change directory to the C:\Program Files\ Common Files\Enterprise Single Sign-On\ folder.

4. From the command prompt, execute the following command:

ssomanage -updatedb SSOCluster.xml

5. Verify the master secrete server name has been changed to  as shown below:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage -updatedb ssocluster.xml
Using SSO server on this computer
 
Updated SSO global information with the following values -
 
SSO secret server name                  : ServerName Database Cluster
SSO Admin account name                  : NOT CHANGED
SSO Affiliate Admin account name        : NOT CHANGE

image

Creating SSO Cluster Resource

BizTalk Server is not cluster aware. So you must manually create the master secret server cluster resource. You can either create a dedicated virtual server (cluster group) for the SSO cluster resource, or use an existing cluster group. The instructions provided use the SQL Server Cluster Group. If you create a dedicated cluster group, you also need to create a network name cluster resource depended by the SSO cluster resource.

To Create SSO cluster resource

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. In the left pane, expand CLUSTER NODE A, expand Groups, and then expand SQL Server Cluster Group. If you get a prompt before it opens Cluster Administrator, choose Open Existing Cluster, and point it to CLUSTER NODE A.

4. Right-click SQL Server Cluster Group, click New, and then click Resource.

5. From New Resource, enter or select the following values, and then click Next.

clip_image002[9]

6. From Possible Owners, verify that CLUSTER NODE A and CLUSTER NODE B are in the Possible owners list, and then click Next.

7. From Dependencies, select SQL Network Name (Cluster Node A) and click Add. And then click Next.

8. From Generic Service Parameters, type or select the following values, and then click Next:

clip_image002[11]

9. From Registry Replication, click Finish.

clip_image001Note
Do not configure any registry keys for replication in the Registry Replication dialog box. Replication of registry keys is not a requirement when creating a SSO cluster resource and, in fact, may cause problems when failover of this cluster resource is attempted.

10. In the details pane, right-click ENTSSO, and click Bring Online. Verify that the state is changed to Online.

Restoring the Master Secret on Cluster Node B

Before restoring the master secret on Cluster Node B, you must make Cluster Node B as the active cluster node, and restart the cluster resource by taking the cluster resource offline and then online.

To make Cluster Node B the active cluster node

1. Log on to Cluster Node B as RBW-NL\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, expand CLUSTER NODE A in the left pane, expand Groups, and then expand SQL Server Cluster Group. In the details pane, the Owner column of the cluster resources shows the active cluster node

4. If Cluster Node B is not the active cluster node, in the left pane right-click SQL Server Cluster Group, and then click Move Group. Wait until all the cluster resources are online.

5. In the details pane, right-click ENTSSO, and then click Take Offline. Wait until all the cluster resources are offline.

6. In the details pane, right-click ENTSSO, and then click Bring Online. Wait until all the cluster resources are online.

To restore the master secret on the second cluster node

1. Copy the master secret backup file, C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak, on Cluster Node A to the same folder on Cluster Node B. SSOSecret.bak is how you named the file when you configured the master secret server on Cluster Node A.

2. Open a command prompt, and then change the directory to C:\Program Files\Common Files\Enterprise Single Sign-On.

3. Type and execute the following command in the command prompt:

ssoconfig -restoresecret SSOSecret.bak

image

Through following this procedure you will be successful in deploying SSO on SQLCluster and configure SSO. My experience is that in following this procedure with an senior administrator inside an organization works the best. This procedure us done with BizTalk Server 2006 R2, but is also suitable for BizTalk Server 2009.

02/28/2012 Posted by | Active Directory, Biztalk, Cluster Configuration, Sql Server, SSO, Windows Server | , , , | 1 Comment

Unable to edit the DCOM settings for IIS WAMREG admin service on a Windows Server 2008 R2 when trying to configure Kerberos Authentication for Role Centers

I came across an issue recently where we were configuring Enterprise Portal and Role Centers to use Kerberos authentication. One of the steps in the whitepaper (and also as given here http://technet.microsoft.com/en-us/library/ee355057.aspx) is to configure DCOM settings to grant the business connector proxy user account Launch and Activation permissions for the IIS WAMREG admin service package. We were able to do this successfully on a Windows Server 2003 R2/2008 system, however on a Windows Server 2008 R2 system the options are all greyed out/disabled in Component Services.

 This is by design. Due to new security considerations, some core system components only grant the local internal account, TrustedInstaller, Full Control permission instead of the local Administrators group.

To be able to modify the settings of IIS WAMREG admin service” on a Windows Server 2008 R2 system, you need to grant the local Administrators group permissions to its registry key as follows:

Registry information: Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

 

1. Run Regedit.exe and browse to “HKEY_CLASSES_ROOT\AppID\{61738644-F196-11D0-9953-00C04FD919C1}” key.
2. Secondary-mouse click on the {61738644-F196-11D0-9953-00C04FD919C1} key and select Permissions
3. Click the Advanced button in the Permissions window and select the Owner tab. Under Change owner to select the local Administrators group and click on Apply, then OK.
4. Then under Permissions window, select the local Administrators group and under Permissions for Administrators select Full Control and click on Apply, then OK.
NOTE: DO NOT modify/change any permissions for the TrustedInstaller account.
5. Re-run the Component Services management console (dcomcnfg.exe) and you should now be able to modify the settings for IIS WAMREG admin service package.
7.Use the following steps to grant the AX Business Connector Proxy User account the Launch and Activation rights

a. Expand Component Services, expand Computers, expand My Computer, and expand DCOM Config.
b. Right-click IIS WAMREG admin Service, and then click Properties.
c. Click the Security tab.
d. Under Launch and Activation Permissions, click Edit.
e. Under Group or user names section, add the Business Connector Proxy User account, and select the user account
f. Under Permissions for the Business Connector Proxy User account, select the Local Launch and Local Activation checkboxes
g. Click OK and OK and close the Component Services management console.

REFERENCES:

The TrustedInstaller account was introduced with Windows Server 2008 – see http://technet.microsoft.com/en-us/library/cc731677(WS.10).aspx for more details.

12/13/2011 Posted by | Delegation, Kerberos, Security, Sql Server | , , | Leave a comment

KERBEROS CONFIGURATION – SPN USAGE

What SPN do I use and how does it get there?

This month has turned into an Kerberos Month for me.   I thought I would share my response to the questions as it will probably be helpful for someone.  Here was the comment that started the conversation.  And, by the way, this was actually a good question.  I actually see this kind of comment a lot in regards to SPN placement.  Not necessarily the setup aspect of it, but for SPN’s in general.

“In prior versions of setup we used to be able to specify the port number for the default and Named Instance.  Now, (SQL 2008 & R2) it takes the defaults.  1433 and Dynamic for Named Instances.

If you want to use Kerberos with TCP, you need to know the port number to create the SPN.  For Default instances, if you’re using 1433 then you’re ok. But, Named Instances listen on a dynamic port by default, and since you can’t set the port number, any SPN you create will probably be wrong and Kerberos won’t work.  It would be great if we could ask the user if they want to change the port number during setup, like we did with SQL 2000.”

Let’s have a look at Books Online first.

Registering a Service Principal Name     http://msdn.microsoft.com/en-us/library/ms191153.aspx

This article goes through the different formats that are applicable to SQL 2008 (they are the same for R2 as well).  It also touches on two items that are important to understand.  1.  Automatic SPN Registration and 2. Client Connections. Here is the excerpt from the above article in regards to Automatic SPN Registration.

Automatic SPN Registration

When an instance of the SQL Server Database Engine starts, SQL Server tries to register the SPN for the SQL Server service. When the instance is stopped, SQL Server tries to unregister the SPN. For a TCP/IP connection the SPN is registered in the format MSSQLSvc/<FQDN>:<tcpport>.Both named instances and the default instance are registered as MSSQLSvc, relying on the <tcpport> value to differentiate the instances.For other connections that support Kerberos the SPN is registered in the format MSSQLSvc/<FQDN>:<instancename> for a named instance. The format for registering the default instance is MSSQLSvc/<FQDN>.

Manual intervention might be required to register or unregister the SPN if the service account lacks the permissions that are required for these actions.

What does this mean?  It means that if the SQL Service account is using Local System or Network Service as the logon account, we will have the permission necessary to register the SPN against the Domain Machine Account.  By default, the machine accounts have permission to modify themselves.  If we change this over to a Domain User Account for the SQL Service account, things change a little.  By default a Domain User does not have the permission required to create the SPN.  So, when you start SQL Server with a Domain User Account, you will see an entry in your ERRORLOG similar to the following:

2010-03-05 09:39:53.20 Server      The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.This permission is called “Write servicePrincipalName” and can be altered through an MMC snap in called ADSI Edit.  For instructions on how to modify this setting, refer to Step 3 in the following KB Article.  WARNING:  I do NOT recommend you do this on a Cluster.  We have seen issues with this causing connectivity issues due to Active Directory Replication issues if more than one Domain Controller is used in your environment.

How to use Kerberos authentication in SQL Server     http://support.microsoft.com/kb/319723

clip_image002

So, if I enable that permission, lets see what the SQL Service does.  I have two machines I’m going to use for this.  ASKJCTP3 (running the RC build of 2008 R2) and MySQLCluster (SQL 2008 running a Named Instance called SQL2K8).

SetSPN Details:

SPN’s with TCP and NP enabled on Default Instance:

C:\>setspn -l sqlservice      Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local:               MSSQLSvc/ASKJCTP3.dsdnet.local:1433               MSSQLSvc/ASKJCTP3.dsdnet.local

SPN’s with only NP enabled on Default Instance:C:\>setspn -l sqlservice      Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local:               MSSQLSvc/ASKJCTP3.dsdnet.local

SPN’s with TCP and NP enabled on Clustered Named Instance: C:\>setspn -l sqlservice      Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local:               MSSQLSvc/MYSQLCLUSTER.dsdnet.local:54675               MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8

SPN’s with only NP enabled on a Clustered Named Instance:C:\>setspn -l sqlservice      Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local:               MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8

Lets look at what the client will do.  When I say client, this could mean a lot of different things.  Really it means an Application trying to connect to SQL Server by way of a Provider/Driver.  NOTE:  Specifying the SPN as part of the connection is specific to SQL Native Client 10 and later.  It does not apply to SqlClient or the Provider/Driver that ships with Windows.Service Principal Name (SPN) Support in Client Connections     http://msdn.microsoft.com/en-us/library/cc280459.aspx

Based on this, if I have a straight TCP connection, the Provider/Driver will use the Port for the SPN designation.  Let’s see what happens when I try to make connections using a UDL file.  For the UDL I’m going to use the SQL Native Client 10 OleDb Provider.  Starting with SNAC10, we can specify which SPN to use for the connection.  This provides us some flexibility when we control how the application is going to connect.  Note:  This is not available with the Provider/Driver that actually ship with Windows.  I also will show what the Kerberos request looks like in the network trace.  This will show us, what SPN is actually being used.  All of these connection attempts were made using ASKJCTP3 which is a Default Instance.

Being this is a Default Instance, I added the Instance Name SPN manually.

C:\>setspn -l sqlservice      Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local:               MSSQLSvc/ASKJCTP3.dsdnet.local:MSSQLSERVER               MSSQLSvc/ASKJCTP3.dsdnet.local:1433               MSSQLSvc/ASKJCTP3.dsdnet.local               MSSQLSvc/MYSQLCLUSTER.dsdnet.local:54675               MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8

Straight TCP with no SPN Specified:

clip_image002[5]

58     1.796875   {TCP:7, IPv4:5}      10.0.0.3      10.0.0.1      KerberosV5    KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/askjctp3.dsdnet.local:1433

TCP with specifying an SPN for the connection:

clip_image004

32     1.062500   {TCP:11, IPv4:5}     10.0.0.3      10.0.0.1      KerberosV5    KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/ASKJCTP3.dsdnet.local:MSSQLSERVER

Forcing Named Pipes with no SPN specified:

clip_image006

68     1.828125   {TCP:21, IPv4:5}     10.0.0.3      10.0.0.1      KerberosV5    KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/askjctp3.dsdnet.local

The way the provider/driver determines which SPN to use is based on the Protocol being used.  Of note, starting in SQL 2008 we allowed for Kerberos to be used with Named Pipes.  If you have a Named Instance and you are using the Named Pipes protocol, we will look for an SPN with the Named Instance specified.  For a Default Instance and Named Pipes, we will just look for the SPN with no port or Named Instance Name specified as shown above.

With the ability to specify the SPN from the client side, you can see how you can easily manipulate, or even see how we will determine what SPN will be used.

Now that we know all of the above, lets go back to the original question.  Your company may or may not want to enable the Write permission for the Domain User Account.  If your company is not willing to open up the permission on the service account, then their only recourse will be to set a static port for the Named Instance instead of letting the Named Instance use a dynamic port.  This would also be my recommendation for Clusters.  In this case, you will need to know exactly what SPN’s are needed and create them manually using SetSPN or tool of your choice.

Even though we don’t provide the ability to set your port during setup, you can still modify the port settings for the Instance through the SQL Server Configuration Manager.  This will allow you to set your static SPN’s as well as assist you with Firewall rules.

image

image

12/09/2011 Posted by | Delegation, Kerberos, Security | , | Leave a comment

   

%d bloggers like this: