When I run my WCF service on my local machine, it works fine. When I deploy the same files to our test server, I get this error when my test client tries to connect to the WCF service:
Security Support Provider Interface (SSPI) authentication failed. The
server may not be running in an account with identity 'host/Server01'.
If the server is running in a service account (Network Service for
example), specify the account's ServicePrincipalName as the identity
in the EndpointAddress for the server. If the server is running in a
user account, specify the account's UserPrincipalName as the identity
in the EndpointAddress for the server.
What does this mean and what area should I be looking to fix? I played around with the web.config identity section, but I'm still unsure what is needed.
I got a similar error before but the message is somewhat different
Right click on the application pool the web site is running under, click on Property then go to the Identity tab. Try to put the "host/Server01" identity in and see if that helps.
This error can also happen for Microsoft Dynamics GP Web Services. In our case, it turns out that the person who set up the GP Web Services used his personal user account as the service account. When he changed his password, it broke the web services.
So, check your user identity and password if your web service used to work but no longer works.
Related
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
HI all I am developing a web API that will be using identity impersonation (using always the same functional identity valid in my domain) to check the status of configuration files of some servers. To do that, I add this to my web.config file
I also set my IIS server to neglate anonymous authentication and accept windows authentication for web service. However when I try to access the status of the files from a browser I noticed that the API is still using NT AUTHORITY\NETWORK SERVICE as the user and, of course, the access to the remote files is denied. Does anyone have an idea of what am I missing?
Thanks
My fault, forgot to set the Authentication mode to Windows in web.config
My web appkication has the following set up..
WCF application hosted on IIS7
Basic HTTP binding - SecurityMode = TransportCredentialOnly and ClientCredentialType = Windows.
.Net 4.0
The app runs in a .Net 4.0 Application Pool using "ApplicationPoolIdentity".
IIS connects to the file system using "Application Pass Through" authentication.
The client and service both run under IIS - that is the client is a webste and the service is an IIS hosted WCF service.
What I would like to understand is that what user accounts are used at the various points in authenticating too and using the service.
I understand that ApplicationPoolIdentity is a built in Windows account that is generated for each created application pool - is this the account under which w3wp.exe will run for the website?
No credentials are specified between clent and server - and this is the most interesting point. When my client connects to my WCF application what identity is used to authenticate to the service. I presume the application pool identity of the app pool hosting client website?
If so then what would happen if the two sites use two differnet app pools?
Or does the service just require a valid account on the machine (or domain) and that is good enough to authenticate?
If I changed the application pool to use a specific user account does this change anything? Again I presume as long as the client passes a valid machine account is that ok?
Also,,,
What identity is used for the file system?
What permissions does "ApplicationPoolIdentity" have on the machine and for the file system.
Finally in the case of SQL Server Integrated security what identity is passed through to SQL server if my service talks to an SQL Server database.
Thanks in advance.
I understand that ApplicationPoolIdentity is a built in Windows
account that is generated for each created application pool - is this
the account under which w3wp.exe will run for the website?
Yes it is. That is called a virtual account which allows IIS to create unique accounts for each defined application pool, also a security identifier is created representing the application pool name. Keep in mind that this is not real user account. For more information about it you can check the following link: http://technet.microsoft.com/en-us/library/dd548356.aspx
No credentials are specified between clent and server - and this is
the most interesting point. When my client connects to my WCF
application what identity is used to authenticate to the service. I
presume the application pool identity of the app pool hosting client
website?
Yes, same rule applies as for using Local Service account or Network Service account.
If so then what would happen if the two sites use two differnet app
pools?
Nothing, unless you elevate the rights of those application pools identities.
Or does the service just require a valid account on the machine (or
domain) and that is good enough to authenticate?
Then you are not going to use the default virtual accounts created for your application pools. Instead you will associate those application pools with existing windows accounts. Keep in mind what sort of permissions those windows/domain accounts have.
If I changed the application pool to use a specific user account does
this change anything? Again I presume as long as the client passes a
valid machine account is that ok?
It would work just fine as long as those accounts will have permissions according to your needs.
What identity is used for the file system?
Define with more details what you mean by file system; are you referring strictly at your application directory?
What permissions does "ApplicationPoolIdentity" have on the machine
and for the file system.
ApplicationPoolIdentity is a member of Users and IIS_IUSRS groups so will "inherit" the permissions of the previously mentioned groups.
Finally in the case of SQL Server Integrated security what identity is
passed through to SQL server if my service talks to an SQL Server
database.
ApplicationPoolIdentity or the account you have configured to be used by your application pool.
I am trying to call a Sharepoint Web Service via WCF from inside a .ASHX on a different server. My code works if I run inside of Visual Studio's debug web server, but not from IIS. The working server works in various authentication modes (Kerberos, NTLM), and the non-working one doesn't work in any. I am impersonating the same user in both cases.
Using NTLM, I recorded a working session and non-working session in Wireshark. In the working one, Wireshark parses the NTLM data and reports a DOMAIN and USER NAME that I expect. In the non-working one, it shows
DOMAIN: NULL
USER NAME: NULL
I have debugged in IIS and impersonation is definitely working at the point of the service call. If I check WindowsIdentity.GetCurrent(), it's the user I expect.
If I inspect the WCF service proxy on the working and non-working servers, they look identical -- the part that deals with ClientCredentials is set to "" for Username and Password for both versions.
Any ideas on what else to check? Why would the NTLM data have DOMAIN and USER NAME set to NULL -- where does it pick that up from?
According to this:
http://support.microsoft.com/kb/207671
When IIS services an HTTP request, IIS performs impersonation so that access to resources to handle the request is limited appropriately. The impersonated security context is based on the kind of authentication performed for the request. The five different types of authentication available from IIS 4.0 are:
Authentication Type Impersonation Type
------------------------------------ ---------------------
Anonymous Access (no authentication) Network
Auto Password Synchronization is
ON (ON=default)
Anonymous Access (no authentication) IIS Clear Text
Auto Password Synchronization is OFF
Basic Authentication IIS Clear Text
NT Challenge/Response Authentication Network
Client SSL Certificate Mapping Interactive
In my case, I have a Network Token, but
Network tokens are "NOT" permitted to access network resources. (Network tokens are named so because this kind of token is traditionally created by a server when a user is authenticated across the network. To allow the server to use a network token to act as a network client and access another server is called "delegation" and is considered a possible security hole.)
The KB has many possible ways to avoid the problem
I'm building an wcf service that is meant to run in an intranet environment using Windows Authentication. I have been merrily working along with some kind of default settings on the local computer.
Problem now is that I need to test it installed to an off site demo computer. I just need to get it running with username password used against the wcf service computer's user accounts.
This is my client code:
using (ImportServiceClient client = new ImportServiceClient("ImportServiceSoap12", REMOTE_ADDRESS))
{
client.ClientCredentials.Windows.AllowNtlm = true;
client.ClientCredentials.Windows.ClientCredential =
new NetworkCredential(userName, password, computerName);
result = client.Sync(items.ToArray());
}
Is it possible to configure the wcf service such that it translates the credential to a windows account on it's machine?
I've been reading contradicting posts here and there, but I feel rather sure IIS shouldn't be part of the authentication. I'm unsure wether ASP.Net authentication node applies or if it's all binding configuration.
Ideally I'd like it to be an NTLM type authentication so that I wouldn't need to set up https.
Is it possible to configure the wcf service such that it translates the credential to a windows account on its machine?
No. Integrated Windows Authentication requires that both the server and the client are part of the same domain (or domains with a trust relationship, in any case). You can't usefully run IWA against local computer accounts on the server.
You will have to use some other (potentially custom) form of authentication and then impersonate to the user you want to run as in the server code.