I want to use a SharePoint 2010 WebService with PowerShell.
But when I execute my code, a error is thrown.
$a = New-WebServiceProxy $url
New-WebServiceProxy : The request failed with the error message:
-- <head><title>Object moved</title></head> <body><h1>Object
Moved</h1>This object may be found...
Any ideas to solve this problem?
You are getting redirected from the service url. Try it in a browser when you are not authenticated and you'll see what is happening.
You need authenticate your request with SharePoint, or make the service available to anonymous users. Pass default credentials (currently logged in Windows user) as follows. This will work if your SharePoint instane is using Windows authentication.
$a = New-WebServiceProxy -Uri $uri -Namespace myNs -UseDefaultCredential
Related
I'm trying to test botframework server on my localhost.
I followed the steps in https://learn.microsoft.com/en-us/azure/bot-service/bot-service-troubleshoot-authentication-problems?view=azure-bot-service-4.0#step-3-enable-security-and-test-on-localhost- .
First I changed app config with the MicrosoftAppId and MicrosoftAppPassword passed the test of https://learn.microsoft.com/en-us/azure/bot-service/bot-service-troubleshoot-authentication-problems?view=azure-bot-service-4.0#step-2 .
Then I started my bot on localhost and the web page shows it was running on http://localhost:3979/ .
But when I tried to test it on the Bot Framework Emulator, it returned 400 directline.postActivity with the message of "Refresh access token failed with status code: 401".
The screenshot is on https://i.loli.net/2019/06/06/5cf88ea120b9973175.png .
My botframework version is 3.13.1.
My Bot Framework Emulator version is 4.3.3.
What should I do to solve this problem?
Thanks for any help.
{
"error": {
"code": "ServiceError",
"message": "Refresh access token failed with status code: 401"
}
}
[11:42:22]POST 201 directline.start Conversation
[11:42:22]Emulator listening on http://localhost:49840
[11:42:22]ngrok listening on https://082d32c4.ngrok.io
[11:42:22]ngrok traffic inspector:http://127.0.0.1:4040
[11:42:22]Will bypass ngrok for local addresses
[11:42:25]->message hi
[11:42:26]POST 400 directline.postActivity
"Refresh access token failed with status code: 401" errors are almost always an issue with appId/appPass.
Please verify:
You have the correct appId/appPass from the App Registration Portal
Note: If you didn't save your password, just click "New client secret" to generate a new one.
Verify you set the correct appId/appPass in web.config
Verify that you entered the correct app/Id/appPass in Emulator:
You should also upgrade Emulator to the latest release. There was a bug in Emulator long before 4.3.3 that caused this error, but I guess there could be something similar with V3 bots, since we rarely use them.
If this is a new bot, you should really be using V4. V3 will be deprecated July 1, 2019. Existing bots will work, but users will no longer be able to create them.
I've developed an UWP app for a client, which uses WebServices that are hosted in its domain.
Until now, the URL WebServices were related to a test server that don't use SSL
But now, the WebServices URL are related to the prod server that use SSL
As I'm a subcontractor, I don't have an AD account, and I need to use the VPN to access to the client's WebServices.
I didn't get any problem to access to the test server, but it's no longer the case with the prod server.
When I try to access to access to the URL through a navigator, I get a security warning message (DLG_FLAGS_INVALID_CA), but I can "force" the navigation to the URL.
But when I call the WebService from the app with HttpCLient, I also get an error (HttpRequestException) and I don't see how I could fix it.
Here are the details of the exception:
HResult = -2147012851
InnerException =
{System.Runtime.InteropServices.COMException (0x80072F0D): Can't find text related to the error code. The certificate authority is invalid or is incorrect at
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task
task) ...
Message = "An error occurred while sending the request."
Source = "System.Net.Http"
I've already tried to install handly the certificates on my computer, but this doesn't fix the issue...
Is there another approach?
Edit: add "user" certificate
The client sent me the "user" certificate and I installed it on my computer in "User\Trusted Root Certification Authorities Certificate Store": there is no longer problem from the navigator. However, in the app, the problem is still present.
Is it normal? Do I need to "attach" the certificate to the app? This is not really usefull, as the client's users don't need this problem: it's only me as I'm a subcontractor using the VPN...
Edit: add "computer" certificate
Finally the client sent me the "computer" certificate and I installed it on my computer in "Computer\Trusted Root Certification Authorities Certificate Store": this time I could use the app without problem.
It's good to know that the UWP app and the navigators don't use the same certificate.
The problem has been fixed by installing the "user" and "computer" certificates that has been sent by the client.
I have the following code to connect to a remote computer:
var credential = new PSCredential(username, securePassword);
var rri = new WSManConnectionInfo(new Uri(uri), schema, credential)
{
AuthenticationMechanism = AuthenticationMechanism.Kerberos,
ProxyAuthentication = AuthenticationMechanism.Negotiate
};
var remoteRunspace = RunspaceFactory.CreateRunspace(rri);
remoteRunspace.Open();
But it's throwing the following exception:
System.Management.Automation.Remoting.PSRemotingTransportException was unhandled by user code
HResult=-2146233087
Message=Connecting to remote server sw-spdev02 failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
The equivalent code in PowerShell ISE is working properly:
$cred = new-object -typename System.Management.Automation.PSCredential `-argumentlist 'domain\user', ('password' | ConvertTo-SecureString -AsPlainText -Force)
$session = New-PSSession http://servername -Credential $cred
As a hint, I was getting this exception in ISE too before I ran this script:
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value http://servername
Another point is that, the computer which the script is running on, and the remote computer are in different domains.
Why am I getting this exception in C# and not in PowerShell ISE?
I don't know why! But I changed the code to this and it worked. I've just set the port number to 5985:
var rri = new WSManConnectionInfo(false, "sw-spdev02.mahanair.aero", 5985, "wsman",
"http://schemas.microsoft.com/powershell/Microsoft.PowerShell", credential)
{
ProxyAuthentication = AuthenticationMechanism.Negotiate,
AuthenticationMechanism = AuthenticationMechanism.Default,
};
Also I've used Username#Domain style instead of Domain\Username as #Donal said in the comments.
I you get that kind of an error when trying to initiate a remote connection and execute commands , most probably you are using the wrong credentials . You might want to cross check your credentials , use the credentials that you use to login to the machine.
Notice that am using the same credentials from the environment variables here:
Sometimes using the environment variables might mislead if your using your Microsoft account to login to your machine. Use your Microsoft credentials instead.
Now it works if you use the same credentials as your Microsoft Account.
I've seen a lot of discussion about "TF400324: Team Foundation services are not available from server", but everything I've read relates to DNS or proxies, and reflect being unable to connect to TFS at all, through any channel. My case is different: I cannot reach my TFS server when using the .NET library, but it works fine using Visual Studio's workflow tools, and I can reach the same URL just fine in a browser.
Zee code, it is here:
private TfsConfigurationServer _server;
...
Uri url = new Uri(serverName + rootFolder);
var creds1 = new NetworkCredential(username, password, Environment.UserDomainName);
var creds2 = new BasicAuthCredential(creds1);
var creds3 = new TfsClientCredentials(creds2) { AllowInteractive = false };
_server = new TfsConfigurationServer(url, creds3);
// Throws Microsoft.TeamFoundation.TeamFoundationServiceUnavailableException
_server.Authenticate();
The creds are needlessly elaborate because I've tried various suggested solutions, but I don't think that's relevant; I get the same behavior with any other creds I've tried, or no creds at all.
If I copy the exact URL to a browser, I can authenticate and proceed. Within Visual Studio I can connect to TFS using Source Control Explorer and other tools, without explicitly authenticating. What might the library want handled differently?
Additional detail from the error:
Team Foundation services are not available from server https://tfs.imahufflepuff.com:8080/tfs/Root/Project.
Technical information (for administrator):
The underlying connection was closed: An unexpected error occurred on a send.
---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
---> System.IO.IOException: The handshake failed due to an unexpected packet format.
We don't have an in-house TFS admin, otherwise I'd kick this issue over to him. I've tried to use Fiddler to get additional detail, but VS consistently refuses to show up there. I can reach an externally-hosted API while debugging, so I don't think there's a network or proxy problem locking down VS.
Have you tried using TfsTeamProjectCollection class instead of TfsConfigurationServer ?
E.g.
Uri url = new Uri(serverName + rootFolder);
var creds = new NetworkCredential(username, password, Environment.UserDomainName);
var server = new TfsTeamProjectCollection(url, creds);
server.Authenticate();
You can also try debugging this issue using Fiddler. You'll have to change VS proxy settings before starting Fiddler:
Either set the registry key reg add hkcu\SOFTWARE\Microsoft\VisualStudio\12.0\TeamFoundation\RequestSettings
/v BypassProxyOnLocal /t REG_SZ /d False
or
Set environment variable TFS_BYPASS_PROXY_ON_LOCAL=0
Seems like an SSL handshake issue at its root, which has nothing to do with the TFS and HTTP protocol and authentication, they sit above SSL. So make sure you have a valid certificate, matching hostname, good validity, accessible CRL where the cert is not revoked, etc. Also check in other browsers or openssl.exe ("openssl.exe s_client -connect servername:8080") for more diagnostic info. You didn't mention but a proxy or an SSL-level certificate authentication could also cause problems, should be easily debuggable by the methods I mentioned above.
Is it possible for a self-hosted OWIN Web API to run under a non-administrator account? I have already tried dozens of url reservations and nothing works. The service fails to start with "Access is denied". It works when the account is added to the administrator role but I don't want that. Code below is running on Win 7 framework 4.5.2.
//install-package microsoft.owin.hosting
//install-package Microsoft.Owin.Host.HttpListener
StartOptions options = new StartOptions();
options.Urls.Add("http://localhost:5000/");
//options.Urls.Add(string.Format("http://{0}:5000", Environment.MachineName));
//options.Urls.Add("http://+:5000/");
//options.Urls.Add("http://*:5000/");
using (WebApp.Start<WebAPISelfHostMinimal.Startup>(options))
{
while (!Terminate)
{
await Task.Delay(10); //keep cpu from getting pegged
}
LogUtil.LogInfo("Terminating owin host.");
}
EDIT - this is running under a Windows account.
C:\>netsh http add urlacl http://+:5000/ user=mini2012\svcAPI
URL reservation successfully added
C:\>sc start apiservice
[SC] StartService FAILED 5:
Access is denied.
C:\>netsh http add urlacl http://*:5000/ user=mini2012\svcAPI
URL reservation successfully added
C:\>sc start apiservice
[SC] StartService FAILED 5:
Access is denied.
C:\>netsh http add urlacl http://localhost:5000/ user=mini2012\svcAPI
URL reservation successfully added
C:\>sc start apiservice
[SC] StartService FAILED 5:
Access is denied.
It looks like the problem was with the URL reservation. I didn't need one. If there is a URL reservation, it will just prevent the owin host from starting with the access denied error. Also, the default port for owin host is 5000. If there is a "dead" process that is still running on that port, it will block your service from starting. To check you can run netstat -a -b at the command prompt.
Your service is running (most likely) under the LocalSystem (SYSTEM) account. This account is not in the Everyone security principal.
In short, to solve this, either make the namespace reservation for Anonymous Logon or change your service to run under the Network Service account which happens to be in the Everyone principal.
Third option is, of course, to create a new local/domain user, create the reservation for it and have the service run under this account. But then you'd have to worry about setting proper security permissions for it, so I'd go with one of the first two options.
Run this command line under admin
netsh http add urlacl url=http://*:8080/ user=MyUser