This post will detail how to configure the ESB management portal on a multi-machine environment with minimal access configuration in mind. The environment consists of mainly three server roles:
1. An active directory server role.
2. A SQL server role.
3. An application server role hosting both the BizTalk server along with the management portal itself.
Assume that we have the domain name as: esbtest.local
The ESB Management Portal, included as part of the Microsoft BizTalk ESB Toolkit, is a sample site that demonstrates the use of metrics and the possibilities that exist for extending the BizTalk ESB Toolkit. The portal provides a starting point from which you can build your own customized portal.
The ESB Management Portal is also a highly capable and useful tool that can help to maximize the use and efficiency of the ESB exception management system. In addition, the portal provides a user interface for an underlying Universal Description, Discovery, and Integration (UDDI) registry server and graphical configuration capabilities for features such as auditing, viewing history information, configuring alerts and notifications, and allowing users to subscribe to alerts that indicate faults occurring in ESB applications.
These steps need to be performed prior to installing the ESB management portal as per the next section. These include creating the domain passwords and granting them the proper rights.
During the setup process you will need to have created a service account that will be used for the following.
1- Web applications (Portal, Exceptions service, UDDI service, and BAM service).
2- The Alerts windows service.
3- The UDDI publisher windows service.
This account will not be used to access any SQL server databases as all SQL access will be done impersonating the portal user account. In this case we will not need to have created any access rights on SQL server side for this account.
This account will need to be used as an application pool so it should be added to the local IIS WPG group. It will also be accessing the ESB Toolkit event viewer so it should have write access to the “Applications” event log.
Assume we created the account as “saESBPortalAppPool”.
We will create also a new group that will include all the ESB portal administrators. Call this group “gEsbPortalAdmins” for example.
Since this user will be used to impersonate the portal user identity and it will try to access SQL server resources using this user identity; a double hop will happen and to allow this user identity delegation rights should be given to the application pool user used. The procedure steps to perform this are listed below.
1. Log on to the domain controller.
2. Open a command prompt.
3. Run the following set of commands:
setspn -A HTTP/<ApplicationServer1Name> ESBTEST\<ESBPortalAppPool> setspn -A HTTP/<ApplicationServer1Name>.esbtest.local ESBTEST\<ESBPortalAppPool>
setspn -A HTTP/<ApplicationServer2Name> ESBTEST\<ESBPortalAppPool> setspn -A HTTP/<ApplicationServer2Name>.esbtest.local ESBTEST\<ESBPortalAppPool>
By running these commands, the user can use any of the names when calling the Web or Windows Communication Foundation (WCF) service. OR if you are using the portal using a load balancer then you need to run the commands:
setspn -A HTTP/<LoadBalancerName> ESBTest\<ESBPortalAppPool> setspn -A HTTP/<LoadBalancerName >.esbtest.local ESBTEST\<ESBPortalAppPool>
For our test environment we have only one server with no load balancer so we issue the commands:
setspn -A HTTP/ESB-Test-Bts ESBTEST\saESBPortalAppPool
setspn -A HTTP/ ESB-Test-Bts.esbtest.local ESBTEST\saESBPortalAppPool
· If SQL is running under a domain identity, run the following commands: setspn -A MSSQLsvc/<Database Cluster Name>:<Named Instance Port Number> ESBTest\<SQL server service account> setspn -A MSSQLsvc/<Database Cluster Name>.esbtest.local:<Named Instance Port Number> ESBTest\<SQL server service account> The following provides more information about the preceding commands:
a. Named Instance Port Number is the port number that the named instance hosting the application databases is using.
b. MSSQLsvc is the SQL service for which you are registering the Service Principal Name (SPN).
By running these commands, the user can use any of the names when connecting to an instance of Microsoft SQL Server.
An example of these commands in our test environment are as follows. Assuming that we have a named instance working on the port 55738.
setspn -A MSSQLsvc/ESB-Test-SQL:55738 ESBTest\saSQLSvcESB setspn -A MSSQLsvc/ESB-Test-SQL.esbtest.local:55738 ESBTest\saSQLSvcESB
2. Start the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.
3. In the left pane of the MMC snap-in click Users.
4. In the right pane, double-click the account identity under which your application pool runs (ESBTEST\<ESBPortalAppPool>) to display the Properties dialog box.
5. On the Delegation tab of the Properties dialog box for the WCF server computer, Do not trust the user for delegation is selected by default. Select Trust this user for delegation to any service (Kerberos only). This is shown in the snapshot below.
Install the MSCHARTS package on the server.
You need to create the ESB portal management database ESBAdmin on the SQL server cluster.
You need to install the ESB management portal web application and the supporting WCF services on both application servers that will be hosting the portal. Follow the following steps to complete the installation and configuration of the web applications.
1- Open the IIS management console by running the command INETMGR
2- Expand the server node.
3- Right click on “Application Pools” and click add application pool.
4- Enter the name to be “ESBPortalAppPool”.
5- Select .NET framework 4.
6- Make sure “Classic” mode is used.
7- Click ok.
8- Click on the “Application Pools” node from the left.
9- Right click on the application pool “ESBPortalAppPool” and click advanced settings.
10- Make sure you set enable 32 bit applications to false.
11- Under identity click on the ellipses button.
12- Enter the application pool domain account already created previously in the preparation steps.
1- Open the folder where you have built the ESB management portal installation package.
2- Run the Setup.exe
3- Select the ESBPortalAppPool as the web application pool.
4- Finish the installation.
3- Expand the node “Default Web Site”.
4- Click on the web application “ESB.Portal”.
5- Double click in the right panel on the “Authentication” icon under IIS category.
6- Make sure that it is configured as the below screen:
7- Right click on “Windows Authentication” and click “Advanced”.
8- Make sure you uncheck the check box for the Kernel mode authentication.
9- Click ok.
10- Right click on “Windows Authentication” and click “Providers”.
11- Remove all providers added by default and only add the “Negotiate:Kerberos” provider.
1- Open the Web.config file from the folder “C:\inetpub\wwwroot\ESB.Portal” in notepad
2- Search for the DB connection string “AdminDatabaseServer” near the top of the file.
3- Change the connection string to the proper value to connect to the SQL server database already created ESBAdmin.
4- Make sure that we have an authorization line for the “gEsbPortalAdmins” group.
5- Search in this file for any occurrence of “Ntlm” and replace that with “Negotiate”.
6- Save the file and close it.
7- Open the Web.config file from the folder “C:\inetpub\wwwroot\ESB.Portal\Admin” in notepad
8- Make sure that we have an authorization line for the “gEsbPortalAdmins” group.
9- Save the file and close it.
1- Open the Web.config file from the folder “C:\inetpub\wwwroot\ ESB.Exceptions.Service” in notepad
2- Search for the DB connection string “EsbExceptionDbConnectionString” near the top of the file.
3- Change the connection string to the proper value to connect to the SQL server database of the ESB exceptions default name is “EsbExceptionsDb”.
4- Search in this file for any occurrence of “Ntlm” and replace that with “Negotiate”.
5- Save the file and close it.
1- Open the Web.config file from the folder “C:\inetpub\wwwroot\ESB.UDDI.Service” in notepad
2- Search for the UDDI server URL string “http://esbwssit.esbtest.local/uddi” and change all occurrences with the proper location of the UDDI server was deployed on.
3- Save the file and close it.
1- Open the Web.config file from the folder “C:\inetpub\wwwroot\ESB.BAM.Service” in notepad.
2- Search for the DB connection string “BAMEventSource” near the top of the file.
3- Change the connection string to the proper value to connect to the SQL server database of the ESB exceptions default name is “BAMPrimaryImport”.
4- Save the file and close it.
Make sure that the services installed “ESB.BAM.Service”, “ESB.Exceptions.Service”, and “ESB.UDDI.Service” are all using the application pool created earlier for the ESB portal.
This will be done for the web applications “ESB.BAM.Service”, “ESB.Exceptions.Service”, and “ESB.UDDI.Service”.
4- Click on the web application to change. (this should be done for the three listed applications above)
7- Right click on “Windows Authentication” and click “Providers”.
8- Remove all providers added by default and only add the “Negotiate” provider.
You need to go through the below steps to verify that it is configured as shown.
3- Click on the node “Default Web Site”.
4- Click on “Configuration Editor”.
5- Open the Section combo box and select the handlers node under “system.webserver”
6- Make sure in the actions pane it is saying Lock and not unlock as per the screen below.
7- If it is saying unlock then press it to unlock this section.
8- Open the Section combo box and select the modules node under “system.webserver”
9- Make sure in the actions pane it is saying Lock and not unlock as per the screen below.
10- If it is saying unlock then press it to unlock this section.
This is needed as the portal will impersonate the identity of the user and if an error happens then it will need this write access to allow it to write to the server event log. To perform this follow these steps on all servers hosting the portal.
1- Download the PsTools from the link: http://technet.microsoft.com/en-us/sysinternals/bb896649
2- Extract the download to any folder.
3- Open a new command prompt window.
4- Change to the PsTools folder.
5- Execute the command “PsGetSid.exe gEsbPortalAdmins”.
6- Mark the SID returned by this command as it will be needed later.
7- Execute the command “wevtutil gl Application”.
8- Under the section “channelAccess:” copy the entire string starting with “O:BAG:SYD:”.
9- Execute the command “wevtutil sl Application /ca:O:<Copied Channel Access string got in step 8>(A;;0x3;;;<Group SID got in step 6>)”
This is needed to allow the operators group to get the list of BizTalk applications from the portal.
1- Open “Computer Management”.
2- Expand “Services and Applications”
3- Left click on “WMI Control”.
4- Then right click on “WMI Control”.
5- Click “Properties”.
6- Click “Security” tab
7- Expand the root one level.
8- Search for “Microsoft BizTalk Server” then click “Security”
9- Click “Advanced”
10- Make sure that the check box below is checked and click “Add”
11- Search for the operators’ group “gEsbPortalAdmins” and give it “Allow” access to everything as below.
12- Click ok and close the computer management.
This is needed to give the operators group the required database access to the BizTalk server databases. This can be done in two ways.
1- Either we give the operators group the same access level as the BizTalk operators group on all BizTalk databases using SQL server management studio. This should be done on all BizTalk databases.
a. Add a new login to the group “gEsbPortalAdmins” to the SQL server.
b. Under the tab “User Mapping” make sure you select the databases BizTalkDTADb, BizTalkMgmtDb, and BizTalkMsgBoxDb
c. Under each database make sure that the user has the database role “BTS_OPERATORS” selected.
2- OR Add the group as a sub group to the BizTalk operators group and convert the BizTalk operators group to be a universal group.
This is needed to allow proper operation on the portal functionality. This should be done using the SQL management console.
1- Open the SQL management console.
2- Open the database ESBExceptionsDb and expand the security node.
3- Add a login for the group “gEsbPortalAdmins”. If not already added.
4- Give that group the database roles ESBPortal and ESBPortalAdmin roles
2- Click on the Application pool on the left.
3- Click on the management portal application pool.
4- Click on the right panel recycle.
This is a fantastic blog post Mohammed. Thanks especially for your guides on taking care of the SPNs. I've added a reference to this post in my blog entry dealing with esb portal multi server security - adventuresinsidethemessagebox.wordpress.com/.../esb-toolkit-2-1-multi-server-security-considerations
Seconded ... excellent and very useful blog post