I have a WebApi (.Net Core 2, Windows Authentication) endpoint that I can successfully call from many combinations of PS/Windows versions:
Invoke-RestMethod -Uri https://<fqdn>/api/notification -UseDefaultCredentials
But when I run it locally on the server hosting the web application (using same AD account) it fails to authenticate. IIS logs for requests from other computers show the user account making the request, but the local requests show empty value for that field.
PS error:
HTTP Error 401.1 - Unauthorized You do not have permission to view
this directory or page using the credentials that you supplied.
IIS log entry:
2018-06-12 21:42:31 GET /api/notification - 443 -
Mozilla/5.0+(Windows+NT;+Windows+NT+6.3;+en-US)+WindowsPowerShell/5.1.14409.1012
- 401 1 3221225581 0
An entry from any other machine besides the local server would have the DOMAIN\User after the port number and would be successful.
Disable strict name checking. The following is a summary from the article:
https://www.andrewcbancroft.com/2016/01/21/401-unauthorized-browsing-site-from-local-iis-instance/
Steps...
Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, refer to article 281308 in the Microsoft Knowledge Base.
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service. (to do this, I ran iisreset from a Powershell prompt)
Related
I have a C# console app that I wrote that is trying to enable mail for an AD user.
using (Runspace EnableMailboxRunspace = RunspaceFactory.CreateRunspace(ConnectionInfo(ExchangeServerURI, ExchangeUser, ExchangePassword)))
{
EnableMailboxRunspace.Open();
// Create a pipeline to process the commands
using (Pipeline EnableMailboxPipeline = EnableMailboxRunspace.CreatePipeline())
This works just fine in the dev environment, but I cannot get it to run on any production server. When the CreatePipeline command is executed I get this error:
"Connecting to remote server pc799.csnt.princegeorge.ca failed with
the following error message : The WinRM client cannot process the
request. It cannot determine the content type of the HTTP response
from the destination computer. The content type is absent or invalid.
For more information, see the about_Remote_Troubleshooting Help
topic."
I have tried this running as multiple different users, including domain admins.
This app did work a few months ago, but now it doesn't work. We moved from a fully on prem system, to a hybrid M365/On prem system and something in that seems to have broke it.
I have a few files that need to be copied from a Server A to Server B. There is an IIS service running on Server B which calls a local powershell script to do the needful.
When the powershell script is executed from the command line, it works as expected and also works when executed from within IISExpress. But when called from the service hosted on IIS, there is no error reported, but no files get copied either.
The powershell script basically calls Copy-Item -Path \\Server A\<some path> -Destination c:\<some path>
Thank You!
IIS by default runs as a local service account that doesn't have network permission. You probably couldn't see an error message because the Powershell script wasn't echoing it's output to the HTTP response.
To fix this you can create a new Application Pool in IIS and set the identity by entering network credentials in the AppPool's Advanced Settings -> Identity.
Then make your Service run in that AppPool by right-clicking on the Virtual Directory and selecting "Add Application". A dialog box will appear where you can select the new AppPool.
Notes:
The credentials you enter in the AppPool are not updated when the network password changes, so you should use a domain account with a password that doesn't expire.
You should not use your own account because it could get locked out if your password changes and your service is invoked.
The password is readable by any administrator on the IIS server.
When I am trying to process dimensions after creating a data source view I get the error:
The project could not be deployed to the server because of the following connectivity problems : A connection cannot be made. Ensure that the server is running. To verify or update the name of the target server, right-click on the project in Solution Explorer, select Project Properties,click on the Deployment tab, and then enter the name of the server.
I have checked in task manager & SQLBrowser is running. Why am I getting this error?
I was able to get the SQL Server instances on my computer this way:
Start Menu
Microsoft SQL Server 2008 or your version
Server Installation Center
Admin login
Select "Tools" from left menu
Select "Installed SQL Server features discovery report"
You then get a nice HTML web page. You want to look for Database Services. You should see an instance name. Mine is called "SQLEXPRESS." So the combination of server name and instance would be MYCOMPUTER\SQLEXPRESS given that my computer name is MYCOMPUTER.
BTW, the default instance name is MSSQLSERVER.
Alternatively, you can get it from your registry. Just run regedit and look for this key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL
Check that the SQL Server service itself (or MSSQLSERVER) is running. Also check the connection string.
If you want to deploy the project to a named instance of Analysis Services on the local computer, or to an instance on a remote server, change the Server property to the appropriate instance name, such as <InstanceName>.
https://learn.microsoft.com/en-us/analysis-services/multidimensional-tutorial/lesson-2-5-deploying-an-analysis-services-project?view=asallproducts-allversions
You need the server name and the instance name.
Open port 2382,2383 to server solve this issue for me.
I installed Kerberos for Windows on a new set-up Windows 8.1 machine.
Domain: not set
Workgroup: WORKGROUP
I edited the krb5.ini file in C:\ProgramData\MIT\Kerberos5 directory like this:
[libdefaults]
default_realm = HSHADOOPCLUSTER.DE
[realms]
HSHADOOPCLUSTER.DE = {
admin_server = had-job.server.de
kdc = had-job.server.de
}
After a restart, I made a kinit -kt daniel.keytab daniel to authenticate me against the Realm via console. Also getting a ticket by user and password via the Kerberos Ticket Manager seems to work fine, as the ticket is shown in the UI.
What I'm wondering about is, that when I call a klist I get an empty list back, which says something like cached tickets: 0:
This seems not normal to me, as my Ubuntu computer shows valid tickets by klist after a kinit.
What am I doing wrong? Is there some more configuration to do? Sometimes I read about a ksetup tool, but I don't know which settings here are neccessary and which not...
============================================================
After I set
[libdefaults]
...
default_ccache_name = FILE:C:/ProgramData/Kerberos/krb5cc_%{uid}
in my krb5.conf, the kinit command via console and via Kerberos Ticket Manager creates a file in the specified path. So far everything looks good.
But: The kinit command creates tickets with very different file names (long vs. short), depending if I run the console as "admin" (short name) or not (long name), see the screenshot below. The Kerberos Ticket Manager only shows one of the tickets:
If run as admin:
Shows the ticket I created via admin console
Creates ticket files with short file names
If run as normal:
Shows the ticket I created via "normal" console
Creates ticket files with long file names
The klist command still doesn't show the cached tickets, independent if console was opened as admin or not.
The MIT Kerberos documentation states that...
There are several kinds of credentials cache supported in the MIT
Kerberos library. Not all are supported on every platform ...
FILE caches are the simplest and most portable. A simple flat file format is used to store one credential after another. This is the
default...
API is only implemented on Windows. It communicates with a server process that holds the credentials in memory... The default
credential cache name is determined by ...
The KRB5CCNAMEenvironment variable...
The default_ccache_name profile variable in [libdefaults]
The hardcoded default, DEFCCNAME
But AFAIK, on Windows the hard-coded default cache is API: and that's what you can manage with the UI. kinit also uses that protocol by default.
I personally never could use klist to use that protocol, even with the "standard" syntax i.e. either
klist -c API:
or
set KRB5CCNAME=API:
klist
On the other hand, if you point KRB5CCNAME to a FILE:***** then you can kinit then klist the ticket; but it will not show in the UI and will not be available to web browsers and the like.
If klist command doesn't show the keys even after setting environment variable like KRB5CCNAME (i.e. set KRB5CCNAME=C:\kerberos_cache\cache\krb5cache, its a file not a directory. You'll have to create parent directory manually), then chances are that the klist command that you're running is not from MIT Kerberos Windows installation in C:\Program Files\MIT\Kerberos\bin but rather the klist command from Windows itself in C:\Windows\system32.
You can check that out by running which klist if you have cygwin tools. In this case, simplest solution is to copy klist.exe into MIT Kerberos installation's bin directory as a new file i.e. klist_mit.exe. Cache entries should be shown if you run klist_mit command.
Typically I remote into a machine with IP Address 00.00.00.00 and then I have an account in a domain, let's call it myspecialaccount\firstname.lastname.
Then I use Windows auth to connect to SQL Server instance for example:
ABCLACSQLC123\DEV04A
So my question is HOW can I connect from my laptop through SSMS directly to the machine (pending ports are open etc..)
In order to use Windows Authentication, you'd have to add the credentials you use to login to the laptop as a "Login" to the SQL Server. That can only be done if
You login to your laptop with a domain user and
The user is in the same domain in which your SQL Server instance resides
Otherwise, you have no choice but to use SQL Server Authentication.
In this case, you login to your laptop with a user in "Corp" domain, but SQL Server instance is in "Services" domain. So it won't work. Unless I think both domains are part of the same Forest.
Look at this answer : https://stackoverflow.com/a/1615431/3317709. There is no trick to login, unless you get rid of the "Network related..." error. If you are getting this error, SSMS is not even able to find your server let alone logging into it. Once you get "Login failed..." error, from that point, we can tinker and try to get thru using your windows auth.
Try creating a shortcut to runas.exe, pointing to SSMS.
C:\Windows\System32\runas.exe /netonly /user:myspecialaccount\firstname.lastname "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
(The path to your SSMS exe may vary.)
When you double-click the shortcut, this will open up SSMS. You should then be able to connect to your instance (ABCLACSQLC123\DEV04A) as if it were on your local machine.
See here for more info on the runas command: https://technet.microsoft.com/en-us/library/cc771525.aspx
Install SQL Server Management Studio Express on your laptop. Microsoft has made the download link obscenely hard to find on their own site, but I did manage to find it here. Download the one for your system, probably x64.
Installation isn't much easier. Once everything is extracted, run the program, and switch to the installation tab, and choose "Standalone installation or add new features". Continue along the installation, and just install the management tools.
Once installed and running, use the Connect to Server dialog (it should open when you start the program, but if it doesn't, it's the first option under the File tab), and target wherever you want to connect (IP or server name should both work). If your laptop also authenticates to the same server that handles Windows authentication for your database, you can use Windows authentication, otherwise, you'll have to create a SQL Server account to use for login.