I've been chasing this problem around for a while now and I can't get to the bottom of it. I've read the other solutions on here (https://identityserver4.readthedocs.io and https://github.com/IdentityServer/IdentityServer4.Quickstart.UI) and it's still not working, so I've tried to reduce this down to the absolute basics. This is not the actual problem I am facing, but produces the very same outcome. i.e. I can't get Windows Authentication to work.
I clone https://github.com/IdentityServer/IdentityServer4.Samples
I amend Quickstarts/7_JavaScriptClient/src/QuickstartIdentityServer/Quickstart/Account/AccountController.cs so that WindowsAuthenticationEnabled is true
I then goto http://localhost:5000/account/login and attempt to use the Windows external provider and I get 401.
The only difference with this simple sample here, and what I see on my actual system is that I'm getting challenged for credentials on my real site.
Debugging the code I never see if(HttpContext.User is WindowsPrincipal) succeeding, because it's always a ClaimsPrincipal.
Can someone explain to me what I'm doing wrong?
Do you have windows authentication enabled on your IIS site? This needs to be enabled for your WindowsPrincipal to be assigned. Note that windows authentication only works when running behind IIS or IIS Express.
Related
I'm troubleshooting legacy REST application used by my company (the person responsible for it's implementation is no longer with the firm, and sourcecode is being looked for) and encountered a weird issue, namely providing no auth-data results in 401 (as it should), sending username+password or token results in 403, yet opening url in chrome on my laptop (where I'm logged in to central system) gets the response I expected (file gets downloaded).
Note that all services are supposed to be linked with central AUTHserver for convinience, so my current hypothesis is that different access rights are given depending on auth method used. Is that possible? Is it proper?
I'm not sure how any of this is relevant but:
providing no auth method returns response indicating auth-method as 'negotiate'
providing one of 'standard' auth methods returns 403
using a library that supposedly implements 'negotiate' method to Python's requests (requests-negotiate) returns errors
using PowerShell $client = System.Net.WebClient; $client.Credentials = Get-Credential; client.DownloadFile(url, path) works as intended (file get's downloaded)
I want to be able to download these files from remote server (running linux, so no PowerShell) and not having to download them to my local machine and upload them to my remote workspace.
Any help/suggestions are greatly appreciated.
Apparently the service uses Windows "integrated authentication", ie. NTLM or Kerberos.
It's not straightforward to get that working on Linux, but not impossible either. You will have to join the client to the domain and get a Kerberos ticket to authenticate, which is somewhat off-topic here. Look at SPNEGO on Linux, and this question for example has some hints.
I have a work laptop that resides between a painful corporate proxy during the day. When I'm at home, I don't have to worry about a proxy unless I VPN in.
Is there a way to set-up an automatic github proxy, such that if I'm at work it'll use the corporate proxy, and if I'm at home, it'll remove proxy settings?
Or perhaps a way that attempt 1 is made with a proxy, and attempt 2 is made without?
Thanks for any suggestions!
You can set it manually through pre-defined scripts/functions, as described here:
See nwinkler/bash-it/plugins/available/proxy.plugin.bash
"When working from the office (where I have to use a proxy), I simply call enable_proxy, and when working from home, I call disable_proxy", as detailed here.
You could wrap this in a test, which tries a curl without and then with HTTP(S)_PROXY variable, in order to see which call is successful.
On Linux, that test could be part of your .bashrc, which would allow any new shell session to open itself with the right settings set or not.
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
Ok I am attempting to transfer a manual change to powershell,
Attempting to grant IIS_IUSRS access to /LM/SmtpSvc/ and /LM/SmtpSvc/1/ nodes in the IIS Metabase.
I have googled extensively and can not find an example of what i am looking for.
I have been trying to play with
$smtp = [wmiclass]‘root\MicrosoftIISv2:IIsSmtpServerSetting'
But I am in a little over my head with WMI.
Any help would be appreciated. This setting is required for resolving
This.
Not an exact answer, but the best I have so far. Following the Guide here I chose option 1 and changed the app pool to network service. I will still work on a way to do the permissions settings with powershell.
Update (solution untested)
I found this answer on another post that details how to do it using scripts in the iis6.0 resource toolkit. To get these scripts on server 2012 you have to install the IIS6.0 resource toolkit, the only way i can find to do a silent install of this one was located here from there you can call the scripts using cscript.exe. I stuck with the changing user on the app pool option because it fits in with other things as well.
I'm trying to connect to IBM FileNet from my ASP.Net application using Kerberos. My AppPool is running under LocalSystem account. There is a "Trust computer for delegation" permission at AD. There is impersonation enabled at IIS for application. But I'm still getting
SecurityException: WSE594: InitializeSecurityContext call failed with
the following error message: A specified logon session does not exist.
It may already have been terminated.
What am I missing?
I don't have enough points to comment, so I have to post an answer instead.
You are not really giving enough information here.
Your error is a WSE error, and may not have anything to do with FileNet.
It may help to answer these questions:
Have you already set up FileNet for Kerberos SSO and tested to ensure it works?
What version of FileNet are you running? (If you still have access to FEM, you can use it to test Kerberos.
Why are you using WSE? MS cut support (a long time ago) and has replaced it with WCF. I only ask as you might find it easier to implement WCF.
You might want to give Implementing Kerberos a read.