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.
Related
CONTEXT
My client has an ASP.NET web application running in IIS 10 on Windows Server 2016. The web application needs to access files on network shares on different servers in a WORKGROUP environment. So, I created the same local user account on all servers, set the password to all the local user accounts to be the same, granted said user with full control permissions to the network shares, and reconfigured the IIS application pool to run under the identity of the aforementioned local user account. There is also a custom Windows service running under the same local user account for the same reason: to access files on remote network shares. All of this works fine. The web application and the Windows service can successfully access files from the network shares residing on servers other than the server on which IIS and the custom Windows service are both running.
ISSUE
However, there is a feature in the web application when an authorized user modifies a particular validation matrix record, it triggers a custom command sent to the aforementioned Windows service to cause the service to update its in-memory copy of the validation matrix. This worked fine when the IIS application pool was running under the built-in ApplicationPoolIdentity which apparently has permissions to interact with Windows services. But, the feature fails when the IIS application pool is running under the identity of the aforementioned local user account. The message in the exception is: Cannot open {SERVICE_NAME} service on computer '.'. Again, the Windows service and IIS are running on the same server. And recall that the Windows service is running under the same local user account as the IIS application pool identity.
QUESTION
How do I grant permissions to the local user account to allow said account the ability to issue the custom command to the Windows service from within the ASP.NET web application?
RESOLUTION ATTEMPTS
I've tried using subinacl.exe in an attempt to grant the necessary access but never got it to do anything other than to indicate Done 0, Modified 0, Failed 0, Syntax errors 0. I'm using version 4.2.1.1604 and executing it from an Administrative Command Prompt. The syntax I used was:
subinacl /service customServiceName /grant=localUserAccount
and the result is below
+service customServiceName
/grant=localUserAccount
Elapsed Time: 00 00:00:00
Done: 0, Modified 0, Failed 0, Syntax errors 0
I also tried /grant=localUserAccount=U and /grant=localUserAccount=F but to no avail ... same results as shown above.
I admittedly am not familiar with subinacl.exe and I saw somewhere that someone indicated earlier versions of subinacl.exe are buggy and suggested using version 5.2.3790.1180 which I cannot find. Result: failed.
I have added the local user account to the Administrators group on the server where IIS and the Windows service are running. Result: failed. CORRECTION 02/13/2023: This succeeded but required a server reboot for it to take effect. To be clear, I do NOT want to permanently add this user to the Administrators group. This was simply a test. As far as the server reboot being required for this to take effect is concerned, I tried recycling the application pool in IIS, restarting the Windows service of interest, and restarting the World Wide Web Publishing Service but no joy. Only a server reboot caused the addition of the local user account to the Administrators group to take effect from the standpoint of said local user having permissions to send a custom command to the Windows service from within the web application. I absolutely am inclined to believe that there is a better way to achieve the desired end without adding the local user account to the Administrators group. Surely someone else before me has encountered this and solved it.
The local user account is already set up in the Local Security Policy with the ability to "Log on as a service".
I have reconfigured the IIS application pool identity to NETWORK SERVICE and granted NETWORK SERVICE full control permissions to the network shares (which are on a different server in a WORKGROUP environment, not a domain environment). In this configuration, the feature to update the Windows service works, but access to the network shares is denied ... likely because NETWORK SERVICE is a built-in local account [with no password?? not sure on this] and does not behave the same as a "regular" local user account.
So, I have a catch-22 that has me stumped. I would be grateful for any insight on this dilemma.
Cheers!
Hi I am trying to deploy a website on an Azure VM and I already set all the configuration for make a deployment but this error appears when I tried to publish:
Error Web deployment task failed. (You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") using the Web Administration Service, but it could not be authorized. Make sure you are using the correct username and password, that the site the one you are connecting to exists and that the credentials represent a user who has permissions to access this site.Get more information at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator.
Error details:
You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") through the Web Administration Service, but could not be authorized. Make sure you are using the correct username and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access this site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.
Remote server error: (401) Not authorized. PoC 0
I follow all the steps from here https://github.com/aspnet/Tooling/blob/AspNetVMs/docs/create-asp-net-vm-with-webdeploy.md
Could you please check if is there any IP restriction configured for the resource group in Azure portal as it could be the reason.
Also i would suggest you to put a fiddler and trace the request which is causing the failure.
please check if you are behind any proxy, if yest then try to connect to a network that does not require this SSO through the proxy or use one of the many other ways to publish that do not require an SSO connection from your machine such as, FTP, VSTS, Git etc… and try to deploy it. Most of the time proxies are the reason which could cause failure in deployment.
As a workaround you could ftp to the site & do deployment via that method .
Hope it helps.
I am getting an "Access is denied" error on a 2012 R2 server when my web app on that server tries to access a self-hosted WCF service on that server using named pipes.
I do not have this issue on my development machine (Win 7). I can access the WCF service via the client test app on both the server and my development machine.
If I enable ASP.NET Impersonation on the web site using a user account that has full control permissions to the install folder for the WCF service, then the error goes away. I do not want to use impersonation since I understand it has significant performance penalties (not to mention security issues) and the WCF service is called for every user input during a session.
The strange thing is... If I set the app pool to run as either the user with rights to the service folder as described above or as a user with admin privileges, then I still get the error if ASP.NET Impersonation is disabled. The error will go away only after I enable ASP.NET Impersonation on the web site.
I do not have access to the source for the WCF service.
In this case, the web app was located on the D:\ drive and the Anonymous Authentication user (IUSR) did not have RX permissions to the web app location.
Note that if you are using Windows Authentication, then the same issue occurs if the Windows Authenticated user does not have RX permissions to the location of the web app.
The problem was resolved once I gave the authenticated user the proper permission.
Sometimes the solution really is just plain simple...
"Ain't got no gas in it" - Slingblade.
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.).
Please note: In each step I describe below I'm logged in as the same domain user account.
I have a web application that controls a service on a remote machine (via ServiceController). When I connect to the website remotely and attempt to control the service, I get an InvalidOperationException: Access is denied.
I know it CAN work, because when I connect to the website from the web server (remote desktop in, login as my domain user, then open the webpage), it works as expected.
I have configured IIS and ASP.NET to require windows authentication and impersonation. I log the current thread's principal when this fails, and I see that the thread is running under my identity whether I'm connecting remotely or from the server itself.
I have tried forcing IIS to use Kerberos authentication, NTLM authentication and both at the same time; whether my principal reports its AuthenticationType as "Negotiate" or "NTLM" it doesn't matter. None of them work when I connect remotely (from my local machine)
ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!
What in the heck could be going on here?
Your scenario is delegation and not impersonation. Delegation is hard to achieve and it depends on many thing that are done right.
A place to start would be Kerberos authentication and troubleshooting delegation issues
David Wang blog is a very useful resource on thous issues.
"ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!"
That's a clear indication that you have permission issues. When you run in the debugger you're running as the logged on user, when you're not debugging it runs as whatever IIS is set to use (NETWORK SERVICE by default). Try setting (temporarily!) the Enable anonymous access using your domain account as the user and see if that works. If it does then it means your IIS is not setup properly to impersonate (and it's probably running as NETWORK SERVICE).
Permissions in IIS can be a bitch to fine tune properly...
Good luck!
P/S: This looks more like a network administration question than a programming one (see https://stackoverflow.com/questions/321618/stackoverflow-is-for-programming-questions-here-are-some-better-forums-for-your#321756)