Looking for help with a BizTalk disaster recovery scenario.
We have failed over to our DR server and have restored the database using the Microsoft standard log shipping method. All has run without issues but I cannot change any port settings in the administration console as the admin console is trying to connect to the original SSO servers.
This is the error displayed by the admin console is with just the server names removed. :-
Could not store transport type data for Primary Transport of Send Port 'DRTestAppSendPort' to config store. Both SSO Servers (Primary='{Old clustered SSO instance}' and Backup='{Old app server}') failed. Backup server failure: Could not contact the SSO server '{Old app server}'. Check that SSO is configured and that the SSO service is running on that server.
(Microsoft.BizTalk.ExplorerOM)
The SampleUpdateInfo.xml has been updated correctly and the restore scripts have been run twice now from C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Bins32\Schema\Restore.
The BizTalk management DB contains the correct server name in the [adm_OtherDatabases]
The registry settings are all correct after the scripts have run.
SSOConfig –Status and the SSOAdministration utility report the
correct DR app server as the master secret.
The BizTalk group has been removed and re-added to the administration console.
The SSO master secret has been restored successfully on the DR server.
The windows management instrumentation service has been restarted..
Totally run out of ideas how to fix this, so any ideas would be much appreciated.
The issue's been resolved - there was a step missing in the Microsoft deployment guide, which is documented in a TechNet article.
Here's the step that was missing which has resolved the issue:
(Under Appendix 6):
Update the SSO Server name as displayed in the Group Properties dialog box available in the BizTalk Server Administration console. To update the SSO Server name, launch the BizTalk Server Administration console, click to expand BizTalk Server Administration, right-click the BizTalk Group node and select Properties to display the General tab of the BizTalk Server Administration console. Then enter the name of the Enterprise Single Sign-On server that this computer will use to access the configuration information for the adapters. This is the name of the SSO server used to connect to the SSO database.
Related
I'm trying to set up impersonation/delegation for a web application using ASP.NET 4.5/SQL Server 2016. The goal is to use the Windows authentication on the web application and the SQL Server.
I reproduced on Azure a setup similar to the one which will be used for production, but I can't seem to find what is making the impersonation not working.
Azure VM #1 [machine name: test-iis-server]: Windows Server 2012 running IIS 8.5 and acting as Active Directory Domain Controller
Azure VM #2 [machine name: test-sql-server]: Windows Server 2016 running SQL Server 2016
Azure VM #3 [machine name: test-client]: Windows 10 machine for simulating a user connecting to the website
I created an Active Directory domain named TEST. It is possible to connect to the 3 machines with users created in Active Directory.
IIS Web server configuration:
In the web.config file:
Authentication mode = Windows
Identity impersonate = True
validation validateIntegratedModeConfiguration = False
Integrated security = SSPI
In IIS Manager:
Windows authentication = Enabled (Kernel-mode authentication = Disabled, Providers = Negotiate:Kerberos)
ASP.NET Impersonation = Enabled
Application pool = Integrated Managed Pipeline (Identity = Custom Identity: test\my-svc-account)
In Active Directory Users & Computers
For each computers (web server, sql server and user computer), I went into Properties and checked in the Delegation tab Trust this
computer for delegation to any service (Kerberos only).
SQL Server Configuration
I did not setup anything here. I assumed that ASP.NET will use the credentials of the user logged in the web application to access the
SQL Server database.
Edit: SQL Server service account: test\my-svc-account
Results:
If I don't use impersonation in the web application and use a defined user/pwd login created in SQL Server, my application works normally and I can get the Windows user credential if I want.
Using impersonation, I get a SQL Server connection error when I open the web application page: Login failed for user 'TEST\test-iis-server$'.
Expected behavior:
The web application will log into SQL Server using the credentials used to log into the "test-client" machine.
I've read a lot on how to implement the impersonation/delegation for my solution, but can't seem to find what's wrong. Anyone has any idea where the proble might come from and how I can resolve it?
Edit #1:
From what I've read, it seems like I need to setup SPNs. I'm confused about how to set them up correctly for my double-hop scenario.
I have created a user account in Active Directory to act as a service account. I've set this account to be trusted for delegation.
I use this account as the identity for my application pool in IIS and as the service account of the SQL Server instance.
Yes, you do need to configure SPNs for both the ASP.NET app pool identity, and the SQL Server service account.
It's relatively straightforward, but you need to make sure you get the right values.
In AD Users and Computers find the 'my-svc-account' account and open the properties. Navigate to the attribute editor tab (if you don't see it, enable advanced features through the ADUC 'View' menu). Find the servicePrincipalName attribute and edit it. Add the following:
http/servicename.foo.com
http/servername <== optional
Where service.foo.com matches your DNS name. If this is a CNAME, you need to also include the underlying A record name as well. So if servicename.foo.com maps to whatever.cloudapp.net, you need to add an SPN for whatever.cloudapp.net. This is for IE, because IE is ...dumb... and trying to be smart (it resolves the DNS down to lowest named record and requests an SPN for that).
Then do the same for the SQL Server service account.
MSSQLSvc/sqlserver.foo.com
MSSQLSvc/sqlserver <== optional
This needs to be the FQDN of the SQL Server host.
Lastly, you need to enable Constrained Delegation between the App Pool identity and the SQL Server service account. This is the 3rd radio button in the delegation control. Add the SQL Server SPN as a delegated target.
Restart IIS and SQL. Try browsing to the app. You should now see it connect to SQL as your named user.
Platform: Windows 7 with VS2013, Microsoft Server 2008 R2 and Microsoft SQL Server 2012.
Good Day to All.
My partner and I recently created an MVC application which works in localhost with a local database hosted in Microsoft SQL Server 2012 within the computer.
But now what we would like to do is to host this application on a website for our users to use the application.
Hosting has been done, where we managed to get the front page to show, but the issue lies with database connection to the MS SQL Server 2012 within the server.
When we check our SQL error log we see this:
2015-05-26 12:04:38.26 Logon Error: 18456, Severity: 14, State:
38. 2015-05-26 12:04:38.26 Logon Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Failed to open the explicitly
specified database 'HRMS.Models.EmployeeDBContext'. [CLIENT: <local machine>]
May I seek some advice as to how we can set up the MVC application on the server to talk to the MS SQL 2012 installed within the server?
We're both new to MVC and ASP.Net, Please guide us in the simplest way possible.
Thanks in advance!
Your connection string most probably indicates an integrated authentication (integrated security=true) which means that the identity of the worker process is trying to connect to the database.
The problem is that you haven't set the identity in an explicit way or rather you set it to the Network Service built-in account.
And this account is not listed as permitted to access the database.
You have two options:
add permissions to the Network Service to access the database (not recommended)
create a separate identity (user) in the server's operating system (or a domain account if you have a catalog) and both assign the identity to the application pool in IIS (so that the ASP.NET process is run under this account) and give this user permissions to access the database.
More on that here:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
I installed Audit Vault Server 12 (DB Firewall not installed) in an Oracle Linux VM (VMware) and activated an agent for Oracle 11g Release 2 in Windows 7 x64 VM (VMware)
according to Oracle® Audit Vault and Database Firewall Installation Guide and Administrator’s Guide Release 12.1.0 as follows:
1) ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
Database restart.
2) Register the Oracle Database Host Machine.
3) Deploy Agent and Request Activation on the Host Machine.
4) Create user accounts on the secured targets and set up Oracle AVDF user privileges on an Oracle Database secured target.
5) Register Secured Targets in the Audit Vault Server with user account of stpe 4: jdbc:oracle:thin:#//IP:1521/orcl
6) Configure an Audit Trail in the Audit Vault Server : TABLE - sys.aud$ or DVSYS.audit_trail$, DIRECTORY - directory of audit trail in XML format are saved.
Every step seemed to be installed without any problems.
I turned off firewall just in case.
The Administrator web page of AVDF showed only messages of "request completed" after having configured an Audit Trail in the Audit Vault Server.
But, the collection state was a red downward arrow, and even auditor web page showed same state.
I couldn't view audit trails in the auditor web page.
But, the vault option page (https://IP:1158/dva) showed audit trails in its report page.
What't wrong?
We had a similar issues and after weeks of troubleshooting and redeployment of OAV agent, we figured out that there was a memory leak from OAV server side. SGA parameters at OAV server needs to be tuned properly. Your best bet is open an SR and work with Oracle because it's a bug.
Maybe orcl is the wrong db name
jdbc:oracle:thin:#//IP:1521/xxxx
I'm getting the following error on my dev machine when attempting to manage SSO settings:
ERROR: 0xC0002A0F : Could not contact the SSO server 'SSODB'. Check that SSO is
configured and that the SSO service is running on that server.
The Enterprise Single Sign-On Service, RPC service, and COM+ System Application service were all started when I checked, but I gave them a restart anyway and it didn't fix the problem. I can access the SSODB through SSMS.
I unconfigured SSO through BizTalk and reconfigured it (successfully). Alas, this also did not help.
SSO was previously working fine. I did notice this morning upon reboot that my browser home page was reset back to our corporate site (meaning something may have been pushed to machine this morning when I signed on) but no one else on my team is experiencing the same issues.
I'm not sure what to try next. Anyone have any ideas?
So, is SSO still working for BizTalk? If so, this might just be a simple user level config issue for SSO. based on the browser info, some user local settings may have been messed up. Try this:
CD to "C:\Program Files\Common Files\Enterprise Single Sign-On" Use administrator privileges
Type: ssomanage -server [SSO Server Name Here]
This will reset the SSO Server name for your user account.
I am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?