Im trying to configure ADFS to work as a Claim Provider (I suppose AD will be the identity provider in this case).
Just for simple testing, ive tried the following on windows server 2016 machine:
1) Setup AD and domain = t1.testdom (Its working cause im actually able to login with the domain)
2) Setup DNS. Added a host (A) for adfs as fs.t1.testdom
3) selfsigned certificate (https://technet.microsoft.com/library/hh848633):
powershell> New-SelfSignedCertificate -DnsName "*.t1.testdom"
4) created a dedicated service account for gMSA
5) setup ADFS.
Server name set as fs.t1.testdom
service>authentication method is enabled as form authentication
6) Also fixed the SPN via powershell to make sure all needed SPNs are there and given to the right user account and that no duplicates are found
--
However, when I try to access the login page on browser via https://fs.t1.testdom/adfs/ls I get the error. The log on server manager says the following:
`There are no registered protocol handlers on path /adfs/ls to process the incoming request`
So is there a way to reach at least the login screen? So I can move on to the next error.
this is what I get on the /ls screen:
Finally found the solution after a week of google, tries, server rebuilds etc!
(This guru answered it in a blink and no one knew it!
https://www.experts-exchange.com/questions/28994182/ADFS-Passive-Request-There-are-no-registered-protocol-handlers.html)
The IdP-Initiated SSO page (https://fs.t1.testdom/adfs/ls/idpinitiatedsignon.aspx). Note that if you are using Server 2016, this endpoint is disabled by default and you need to enable it first via the AD FS console or
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
--
My question is, if this endpoint is disabled, why isnt it listed in the endpoints section of ADFS Management console?!!
I'm using the following code in a VB6 DLL (Middleware on an ASP Classic Site) to create a drive mapping to a network share in order to copy files to and fro:
Set ws = CreateObject("WScript.Network")
ws.MapNetworkDrive strDrive, strPath, False, strUser, strPass
At the moment, this works if the share is a normal file server, e.g. \server\share\foo but if I move to a DFS namespace it no longer works, e.g. \mydomain.local\share\foo.
It works in the VB IDE (running as me but using same credentials as the service would) but once compiled and running under the web server the error returned is Error -2147023584 - A specified logon session does not exist. It may already have been terminated.
Most sites I have searched suggest the the local system policy "Network access: Do not allow storage of passwords and credentials for network authentication" be disabled, this is already the case on my machine, I even enabled it then disabled it again to make sure.
Another site suggested connecting to the root node of the DFS first, that didn't work either.
(Windows 7, IIS 7.5)
I am trying to create Client Certificates Authentication for my asp.net Website.
In order to create client certificates, I need to create a Certificate Authority first:
makecert.exe -r -n “CN=My Personal CA” -pe -sv MyPersonalCA.pvk -a
sha1 -len 2048 -b 01/01/2013 -e 01/01/2023 -cy authority
MyPersonalCA.cer
Then, I have to import it to IIS 7, but since it accepts the .pfx format, i convert it first
pvk2pfx.exe -pvk MyPersonalCA.pvk -spc MyPersonalCA.cer -pfx MyPersonalCA.pfx
After importing MyPersonalCA.pfx, I try to add the https site binding to my Web Site and choose the above as SSL Certificate, but I get the following error:
Any suggestions?
I ran across this same issue, but fixed it a different way. I believe the account I was using changed from the time I initially attempted to set up the certificate to the time where I returned to finish the work, thus creating the issue. What the issue is, I don't know, but I suspect it has to do with some sort of hash from the current user and that is inconsistent in some scenarios as the user is modified or recreated, etc.
To fix it, I ripped out of both IIS and the Certificates snap-in (for Current User and Local Computer) all references of the certificate in question:
Next, I imported the *.pfx file into the certs snap-in in MMC, placing it in the Local Computer\Personal node:
Right-click the Certificates node under Personal (under Local Computer as the root)
All Tasks -> Import
Go through the Wizard to import your *.pfx
From that point, I was able to return to IIS and find it in the Server Certificates. Finally, I went to my site, edited the bindings and selected the correct certificate. It worked because the user was consistent throughout the process.
To the point mentioned in another answer, you shouldn't have to resort to marking it as exportable as that's a major security issue. You're effectively allowing anyone who can get to the box with a similar set of permissions to take your cert with them and import it anywhere else. Obviously that's not optimal.
Security warning: what the checkbox really means is that the certificate can be read by users that shouldn't be able to read it. Such as the user running the IIS worker process. In production use the other answer instead.
Happened to me too, and was fixed by ensuring that "Allow this certificate to be exported" is checked when you import it:
(thanks to this post!)
This must be some kind of IIS bug, but I found the solution.
1- Export MyPersonalCA.pfx from IIS.
2- Convert it to .pem:
openssl pkcs12 -in MyPersonalCA.pfx -out MyPersonalCA.pem -nodes
3- Convert it back to .pfx:
openssl pkcs12 -export -in MyPersonalCA.pem -inkey MyPersonalCA.pem -out MyPersonalCA.pfx
4- Import it back to IIS.
We had the same issue due to incorrectly importing the certificate into the Current User Personal certificate store. Removing it from the Current User Personal store and importing it into the Local Machine Personal certificate store solved the problem.
Nobody probably cares about this anymore, but I just faced this issue with my IIS 7 website binding. The way I fixed it was going to the Certificate Authority and finding the certificate issued to the server with the issue. I verified the user account that requested the certificate. I Then logged into the IIS server using RDP with that account. I was able to rebind the https protocol using that account only. No exports, reissuing, or extension changing hacks were needed.
Instead of importing the cert from IIS, do it from MMC.
Then goto IIS for binding.
In our case this problem occurred because we have installed the certificate in a Virtual Machine and made an image of it for further use.
When creating another VM from the image previously created the certificate sends the message.
To avoid this be sure to install the certificate on every new VM installed.
According to the MSDN blog post, this can happen when the current user account doesn't have permission to access the private key file which is under the folder "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys". Apparently this can be resolved by granting the user account / user group Full Access permission to the above folder.
I've come across the same issue, and was able to resolve it by simply re-importing the .pfx file with the Allow this certificate ti be exported checkbox selected.
However, this method imposes a security risk - as any user who has
access to your IIS server will be able to export your certificate with
the private key.
In my case, only I have access to my IIS server - therefore it was not a huge risk.
I got this error due to wrong openssl command-line during export PKCS #12 certificate. -certfile key was wrong. I exported certificate again and it was imported successfully.
We found another cause for this. If you are scripting the certificate install using PowerShell and used the Import-PfxCertificate command. This will import the certificate. However, the certificate imported cannot be bound to a website in IIS with the same error as this question mentions. You can list certificates using this command and see why:
certutil -store My
This lists the certificates in your Personal store and you will see this property:
Provider = Microsoft Software Key Storage Provider
This storage provider is a newer CNG provider and is not supported by IIS or .NET. You cannot access the key. Therefore you should use certutil.exe to install certificates in your scripts. Importing using the Certificate Manager MMC snap-in or IIS also works but for scripting, use certutil as follows:
certutil -f -p password -importpfx My .\cert.pfx NoExport
See this article for more information: https://windowsserver.uservoice.com/forums/295065-security-and-assurance/suggestions/18436141-import-pfxcertificate-needs-to-support-legacy-priv
Guys after trying almost every single solution to no avail i ended up finding my solution to '“A specified logon session does not exist. It may already have been terminated.” when using https" below
Verify your pfx cert is healthy with correct private key
Run certutil and locate the certs 'unique Container name' - i used certutil -v -store my
3.Navigate to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and locate the system file that corresponds to your Container name found above
Check permissions and ensure 'system' has full control to file.
Once applied i then checked IIS and was able to apply to https without error
I had the same issue. Solved by removing the certificate from de personal store (somebody put in it) and from the webhosting. All done through the IIS manager. Then I added again to the webhosting store (with everything checked) and I can use HTTPS again...
In my case it was because the World Wide Publishing Service user didn't have permissions to the certificate. After installing the certificate, access the certificates module in MMC and right-click the certificate with the issue. Select "Manage Private Keys..." from the "All Tasks" menu and add the above user. This was SYSTEM user in my case.
I was getting a this error when trying to bind localhost pfx cert for my development machine.
Before i tried any of this above, tried something simpler first.
Closed any localhost dev site i had openned.
Stopped my IIS server and closed the manager
run the manager as Admin
Added all my https bindings, no errors or issues this time.
restarted iis
Everything seems to work after that.
I was getting same error whilst binding the certificate, but fixed after deleting the certificate and importing again through mmc console.
In my case, it has been fixed by using certutil -repairstore command. I was getting following error, when trying to add certificate to Web Binding on IIS using powershell:
A specified logon session does not exist. It may already have been terminated.
I fixed it by running:
certutil.exe -repairstore $CertificateStoreName $CertThumbPrint
where CertificateStoreName is store name, and CertThumbPrint is the thumbprint of imported certificate.
I recieved this error message when trying to use the following powershell command:
(Get-WebBinding -Port 443 -Name
"WebsiteName").AddSslCertificate("<CertificateThumbprint>", "My")
The solution for me was to go into certificate manager and give IIS_IUSRS user permission to see the certificate.
These are the steps I followed:
Move the certificate into [Personal > Certificates]
Right click [All Tasks > Manage Private Keys]
Add the IIS_IUSRS user (which is located on the local computer not in your domain if you're attached to one)
Give read permission
I managed to fix this problem by importing the SSL certificate PFX file using Windows Certificate Manager.
http://windows.microsoft.com/en-us/windows-vista/view-or-manage-your-certificates
I just had this issue today and feel compelled to post my solution in the hope that you will lose less hair than I've just done.
After trying the solutions above, we had to re-issue the SSL certificate from the SSL provider (RapidSSL issuing as a reseller for GeoTrust).
There was no cost with this process, just the five minute wait while the confirmation emails (admin#) arrived, and we gained access again.
Once we had the response, we used IIS > Server Certificates to install it. We did not need the MMC snap-in.
https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO5757
We kept a remote desktop window to the server open throughout, to avoid any issues with differing login accounts/sessions, etc. I do believe it is an IIS bug as another expert believes, as we only have one RDC account. What is most infuriating is that the very same certificate has been working perfectly for two months before suddenly "breaking".
In my case I imported a newer version of a certificate (PFX for IIS) from StartSSL just recently and forgot to remove the old one, which somehow caused this error (now two certs sort of the same). I removed both of them, imported the proper one, and now it works.
I was able to fix this problem by removing the then importing it by double clicking the certificate.
For me, the fix was to delete the cert from IIS and re-import it, but into the "personal" certificate store instead of "web hosting"
According to the below, this is fine, at least for my own circumstances.
What's the difference between the Personal and Web Hosting certificate store?
Also, should it make any difference, I imported the certificate via the wizard after double clicking on it on the local machine, instead of via the IIS import method. After this the certificate was available in IIS automatically.
Here's what worked for me:
Step 1: Open up a Run window and type "mmc"
Step 2: Click File > Add/Remove Snap In
Step 3: Add > Certificates, Click OK
Step 4: Choose "Computer Account", then "Local Computer" and proceed.
Step 5: Hit OK
Step 6: Right click the Certificates folder on: Console Root > Certificates (Local Computer) > Personal > Certificates
Step 7: Select All Tasks > Import (Please note that the "Local Machine" is selected on the next window)
Step 8: Browse your .pfx file
Step 9: Then go to the IIS and create https binding
Try :
Go into IIS and delete "VSTS Dev Router" web site and "VSTS Dev Router Pool" application pool.
Run “certlm.msc” and open Personal/Certificates
Delete any cert named “*.vsts.me” and "vsts.me"
Re-deploy
I'm building a simple internal application for my company, and it requires Windows Authentication for security. All other authentication modes are disabled. I'm stuck in a situation where internet explorer prompts for credentials 3 times, then fails with this error:
Not Authorized
HTTP Error 401. The requested resource requires user authentication.
I then created a bare-bones website to test this out. I created a new site in IIS, put it on its own port (:8111, chosen at random), put one static "default.htm" file in there, disabled anonymous authentication, then enabled windows authentication. Everything else was left at default settings. The port number was assigned because we have multiple sites on this machine all sharing the same IP.
Here are a few scenarios:
Browsing from the web server itself, to http://localhost:8111/ works
fine
Browsing from another computer, to http://ServerIPaddress:8111/
works fine
Browsing from another computer, to http://ServerName:8111/ FAILS
(asks for credentials 3 times, then gives 401 error)
I've been searching online and trying to find a solution with no luck thus far. Either I haven't found it, or I don't understand well enough what I'm reading. Any help would be greatly appreciated.
Just worked out the solution with the help of a coworker after 2 days of fighting with this issue. Here is what he wrote:
There are 2 providers for Windows Authentication (Negotiate and NTLM).
When setting the Website Authentication to Windows Authentication,
while Windows Authentication is highlighted, click on the Providers
link on the right pane or IIS Manager and move NTLM to the top. By
default Negotiate is on top which is why you are getting an
authentication prompt.
Error 401.1 when you browse a Web site that uses Integrated Authentication.
Solution
Disable the loopback check
* In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
* Right-click Lsa, point to New, and then click DWORD Value.
* Type DisableLoopbackCheck, and then press ENTER.
* Right-click DisableLoopbackCheck, and then click Modify.
* In the Value data box, type 1, and then click OK.
http://support.microsoft.com/kb/896861
If it still does not work after moving NTML to top in the list of providers try to remove Negotiate completely so there is only NTML left.
That fixed it for me - moving NTML to top did not help on Windows Server 2012 and IIS 8.5. I found the solution in the following stackoverflow issue: IIS 7.5 Windows Authentication Not Working in Chrome
I personally recommend NOT disabling the loopbackcheck globally on your server (IE: Do NOT set DisableLoopbackCheck to a value of 1 in your registry). This is a security vulnerability. Please only disable for known hosts.
Here's a Powershell function to get you pointed in the right direction.
function Add-LoopbackFix
{
param(
[parameter(Mandatory=$true,position=0)] [string] $siteHostName
)
$ErrorActionPreference = "Stop"
Write-Host "Adding loopback fix for $siteHostName" -NoNewLine
$str = Get-ItemProperty -Name "BackConnectionHostNames" -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -erroraction silentlycontinue
if ($str) {
if($($str.BackConnectionHostNames) -like "*$siteHostName*")
{
Write-Host "`tAlready in place" -f Cyan
} else{
$str.BackConnectionHostNames += "`n$siteHostName"
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "BackConnectionHostNames" -Value $str.BackConnectionHostNames
Write-Host "`tDone" -f Green
}
} else {
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "BackConnectionHostNames" -Value $siteHostName -PropertyType "MultiString"
Write-Host "`tDone" -f Green
}
Write-Host "`tnote: we are not disabling the loopback check all together, we are simply adding $siteHostName to an allowed list." -f DarkGray
}
> Add-LoopbackFix "ServerName"
Source
It's been a while since this question was asked, but I know numerous people run into it a lot. A more proper fix for this is described here: Kernel-mode authentication. We implemented this several months back, and it works fine.
Another good explanation here: MORE 2008 AND KERBEROS: AUTHENTICATION DENIED, APP POOL ACCOUNT BEING INGNORED
To apply to a single site:
cd %windir%\system32\inetsrv
set SiteName=TheSiteName
appcmd.exe set config "%SiteName%" -section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:"True" /useAppPoolCredentials:"True" /commit:apphost
Or to apply to all sites:
%windir%\system32\inetsrv\appcmd.exe set config -section:windowsAuthentication /useAppPoolCredentials:"True" /commit:apphost
I am working on an ASP.NET WebForms application, and I have been asked to switch from Windows Form Authentication to PKI Certificate Authentication; something I know very little about.
After reviewing various web posts and their code snippets, I thought I knew enough to at least begin sniffing a PKI Certificate (or any client certificate for that matter). Specifically I am using:
X509Certificate2 cert = new X509Certificate2(Page.Request.ClientCertificate.Certificate);
X500DistinguishedName dn = cert.SubjectName;
So I put a breakpoint on the 2nd line, hit F5 from Visual Studio. Debugging starts, but 'cert' is always null. I then realize that I have no Personal certs on my computer, so I download the Firefox add-on Key-Manager, create a dummy certificate, and try again with the same result, 'cert' is always null.
So then, I start screwing around with the command-line tool makecert, but still 'cert' is always null.
I am using IIS Express 7.5 for debugging purposes, tried both http and https.
What do I need to do to attach the personal cert to any web requests, and have them get picked up by my ASP.NET application?
Do you have IIS express setup to require client certs?
Please look here for a similar question/answer:
https://serverfault.com/questions/309690/how-to-configure-iis-express-to-ask-for-client-certificate
http://www.iis.net/ConfigReference/system.webServer/security/authentication/iisClientCertificateMappingAuthentication