Regarding BizTalk 2016, this seems like it should be dead simple, but failing with a security error.
Documentation basically says "Enter the username and password of a user that's a member of the SSO Administrators group."
https://learn.microsoft.com/en-us/biztalk/core/install-and-configure-biztalk-tms-for-fp
I ran BizTalkTMS.msi (to install the Token Manager Service) under my userid (which is also a member of the SSO Admin group as defined in the BizTalk configureation.exe program. It prompts for user/pass to under which the service should run. I put the exact same account "domain\user" that is running the Enterprise SSO and supposedly the correct password.
It returns the error: "BizTalk Server TMS failed to start. Verify that you have sufficient privileges to start system services."
If I'm using the exact same account that is running Enterprise SSO, how could this happen? We've tried about 3 other IDS, and they all give the same error. What could be missing?
Trying to set this up to resolve issue: "Office365 Outlook Email - Sign-In button on Receive Location does nothing" (similar to here)
You have to use both the user that is in the SSO group, and run BizTalkTMS.msi as an administrator. Either do "run as admin" on it, or open a command prompt as admin, then run it from there.
Related
In BizTalk 2016, when I enable a Receive Location using the adapter "Office365 Outlook Email", it raises an error message in the Application Event Log:
Details "Service account does not have sufficient privileges. Please
make sure the service account is a member of the SSO Administrators
account.".
All our host instances run under an account that is BizTalk Admin, but probably not SSO Admin (I will get some with AD to verify). If I remember, that is the minimal security needed. Seems like a bad practice to add that user to SSO Administrator group.
So if I understand, the best practice might be to create another HostApp user account with BizTalk Admin and SSO just for this one adapter. This sounds kind of crazy and overkill to me - but is that what would have to be done?
I'm starting an SSIS package from an .aspx using sp_start_job on the SQL-server.
This package is an import-job, where the destination database is on the same server as the job, so the DestinationConnectionOLEDB uses the same SQL-credentials as for running the job.
However, the source is on another server, and the SourceConnectionOLEDB requires a windows domain account for logon. (The package runs fine from Visual Studio, using my windows account).
I seem to have two possible solutions for the account in the SourceConnectionOLEDB.
either to pass the account of the user who is running the .aspx
or specify a fixed windows account and password in the package.
The last seems not possible to do in Visual Studio, as soon as I select Windows Authentication, the UserID and password field is disabled. Or is there a way of saving this info in the SSIS?
And if not, how do I pass the users windows credentials to the sp_start_job?
If I got it right, you have a SQL Server Agent job that runs an SSIS package, with a step of type "SQL Server Integration Services Package".
You cannot save AD user login info in SSIS (afaik), but you can specify which user runs the job step in SQL Server by setting up credentials and proxy to be used in that specific job step.
When you run the job, it gets executed as the SQL Server Agent Account by default, but you can change that by using credentials and proxy.
The credentials (Security - Credentials) allows you to specify a username and pw (even an AD user), to be used later by a proxy
The proxy (SQL Server Agent - Proxies) allows you to specify which credentials are available to different job step types.
Summary:
Create the credentials object (Security - Credentials) for your AD user
Create the proxy object (SQL Server Agent - Proxies)
use the credentials defined in point 1
enable the subsystem "SQL Server Integration Services Package"
Configure the job step
in the "run as" dropdown you should see the proxy you just created
Of course in your package you must have set Windows authentication for the data source
I have an ASP NET APP that's trying to access a sql server database, when I run it, I get an error saying
"Login Failed for user IIS APPPOOL\DefaultAppPool"
Searching the web I found that I should grant access to this user, so I executed the following script:
grant execute on schema :: dbo to [IIS APPPOOL\DefaultAppPool]
It executed succesfully as a script for my database, but I still get the "Login Failed" error.
What's missing?
Check the user your DefaultAppPool is using to connect.
On your IIS manager check DefaultAppPool advanced properties and look for Identity. You need to give it a user with enough privileges, depending on what your site is going to do.
I usually create different AppPools for different sites depending on what they will do, for example, if your app will write documents to a folder on your server, the user of the AppPool will need writing access to that folder.
Also is not a good idea to use an administrator user, as it could lead to potential security breaches. However it could be a good way to check if your problem comes from there.
I think I already know what it is. When I upgraded SQL Server Express, it installed a new server .\SQLEXPRESS (because I used "new sql instance"), remote connections where configured in this server and not LocalDB, my database was still in LocalDB. But now I get other error, maybe related to WCF Data Services...
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 recently had to change my active directory account password.
Ever since then I am unable to deploy BizTalk projects or put my Receive Locations in the stop state (Sendports & orchestrations is fine).
I noticed that my Enterprise Single Sign-On Service isn't running, if I try to start the service it complains about a login failure.
The thing is, you would think that it used my account to start this service and that it can't login anymore because of some old password or something. However I run the service with another user, namely: BiztalkUser. This user is set on the service and u can also see him in the biztalk server configuration.
Anyone have any ideas what I have to do? Cuz I can't do much anymore now.
The procedures for changing service accounts and password is clearly documented by Microsoft http://msdn.microsoft.com/en-us/library/aa561505(BTS.10).aspx please follow the steps outlined under "Enterprise Single Sign-On Service on Master Secret Server" to correct your issue.
I agreed with the first paragraph of answer 1. That would be the first option I would look to correct the problem. The second option would be, restoring the master secret server.
See below;
Open a command prompt - Navigate to C:\Program Files\Common Files\Enterprise Single Sign-On\
Type in command - ssoconfig -restoresecret SSOXXXX.bak
(Where XXXX is a randomly generated name created with SSO was installed. This is the SSO back-up file)
Enter the password - (Again you entered/created/accepted this when configuring SSO in the BizTalk configuration.)
Additionally you should create a new backup file if you have changed the account the SSO service runs under.
To create a new back-up file - ssoconfig -backupsecret latestbackup.dat
If SSO is running under your account and it stopped working when you changed the password, you need to update your password on the service's credentials. You can do this in the serivces control panel. If you have other BizTalk items running under your account, you will need to update them as well... host instances, application pools, etc.
BizTalk User may not not have the necessary permission to run SSO. I'd suggest put the account back in that worked. Comb the error log for other messages to help you diagnose th eproblem. For furtherhelp, I'd suggest posting more specific details of your current problem here (ie. Error Messages, Log Files, etc.).