I'm attempting to setup ADFS on a Windows Server 2012 R2 box that is part of a distributed setup - 1 Domain Controller, 1 Web Front End, 1 App Server (the problem box) and 1 SQL Server box.
When attempting to configure ADFS with Install-AdfsFarm I get:
“The certificates with the CNG private key are not supported. Use a
certificate based on a key pair generated by a legacy Cryptographic
Service Provider.”
The problem I have, is the exact same certificate is fine when collocating everything on a single box. It's just when I have separate servers the command fails.
How can a certificate be ok for Install-AdfsFarm on one server, but not another?
Unfortunately, ADFS 2012 R2 does not support CNG based certificates. Other versions do support these so that would explain why you are getting this error.
See: https://social.technet.microsoft.com/Forums/forefront/en-US/f0a93670-7912-4f55-b400-cc625d2f90f9/adfs-certificate-for-office-365?forum=ADFS
Related
I've created a self-signed certificate and configured with SQL Server Express. The encryption works fine on my PC.
When I export the certificate to another PC I can import fine and can see the certificate in MMC under Personal > Certificates.
However when I try to configure with SQL Server Express on the new PC, the certificate does not appear in the dropdown.
Any suggestions?
I have tried a few things suggested on other forums
Making sure the private key is exported
Making sure the certificate was created for local system (not user)
Copy certificate into trusted certificates
Look at the properties for the certificate CN value. You will find that it has the "computer name" of the system that you created it on (which means "localhost"). This will not work when you copy the certificate to another system as the machine name will be different.
I am working on a prototype for an upcoming big solution and wish to use Always Encrypted to encrypt certain sensitive database columns.
My setup is a follows:
Database Server: SQL Server 2016 installed
Application Server: Reporting Server 2016 installed pointing to the Database Server engine. IIS, .Net 4.6.2 etc. all setup as well.
The environment is also setup in a way that the DBA can't read the encrypted data even if from Management Studio he will add the 'Column Encryption Setting = Enabled' in the connection. So my certificate is installed on the Application Server while the CMK and CEK are installed on the Database Server database.
I can view the encrypted data from my Web App installed on the Application Server with no problem, and the DBA can't read the encrypted data directly from the database, so I am assuming that my environment is well set up.
As explained I have SSRS 2016 installed on the Application Server but pointing to the database with encrypted columns on the database server. I have done a basic dump report (for testing purposes) using Report Builder of course and all works well EXCEPT that the encrypted data is not displayed - it is remaining blank in the SSRS Table! The encrypted column is just a basic nvarchar(200)
In the datasource connection string I have added 'Column Encryption Setting = Enabled'. Without it the report display #Error as expected. So I am assuming that this is needed as well.
Something also that I noticed is that from the Query Designer I can read the encrypted column. if I remove 'Column Encryption Setting = Enabled' from the datasource the Query Designer displays VarBinary if I remember correctly. I am working with Report Builder and Query Designer directly on the Application server of course.
I tried to search for any tutorials on how to use SSRS with Always Encrypted but I couldn't find anything. All I found is a comment in a post that SSRS supports Always Encrypted.
Can someone please enlighten what I am doing wrong or what I am missing?
Thanks in advance.
Disclaimer: I am a Program Manager at Microsoft.
To troubleshoot your issue, please try to run the problematic query (the one that returns no data in Report Builder) from SQL Server Management Studio on the same machine (that you run Report Builder from) and as the same user, over a connection with 'Column Encryption Setting = Enabled' and see, if you get any error message.
I have seen a query against encrypted columns returning no results in Report Builder, if the certificate is not deployed on the machine, hosting Report Builder, or the user does not have a permission to access the certificate. Do you store the certificate (used as a column master key) in the Current User or Local Machine store? If it is in the Local Machine store, you need to ensure that you (the user who runs Report Builder) have the permissions to access the certificate (you can configure permissions on a certificate using Management Console).
The account that is running the SSRS service needs to have read permission on the Always Encrypted certificate in the Local Machine store. Right click the certificate, select All Tasks – Manage Private Keys and then provide the SSRS service account read permissions on the certificate.
We're working on an implementation of DirectAccess using Windows Server 2012 R2.
The DA server is a single NIC behind the firewall with TCP/443 forwarded for IPHTTPS.
During the initial testing/setup, we set it up strictly for Windows 8.1 clients, using the username/password (computer account) to authenticate. Everything worked beautifully.
Wanting to extend the testing to Windows 7 clients, we configured DA to use certificates for authentication. We have an internal PKI infrastructure that has worked properly for everything else we've needed it for during the last 2 years.
Windows 7 clients, with the DirectAccess Connectivity Assistant, connect and work beautifully. However, Windows 8.1 clients cannot.
We've checked the certificates and all seems good. Using the DirectAccess Troubleshooter, we see that it connects successfully to the DA IPHTTPS URL, however it can't access any internal resources. We can ping the internal DCE addresses x:y:z::1 & x:y:z::2 that it is my understanding are the DA server inside our network.
Are there any additional tools for troubleshooting this? Can anyone point me in the right direction to determine why only Win8 clients won't connect with certificates?
The initial getting started wizard in DA allows Windows 8 / 8.1 to connect using Kerberos Proxy (no certs). A full blown install using PKI mandates that all clients use certificates. Deploy the Computer certs to the Windows 8 / 8.1 and you will be fine.
Reference - http://technet.microsoft.com/en-gb/windows/dn197886.aspx
How does DirectAccess in Windows 8 and Windows Server 2012 simplify deployment?
In earlier versions of Windows Server, a PKI was required to deploy DirectAccess. DirectAccess used the PKI for server and client certificate-based authentication. Now Windows 8 sends client authentication requests by using a Kerberos proxy service running on the DirectAccess server. The Kerberos proxy service sends requests to domain controllers on behalf of the client. As a result, for simple deployments a PKI is not required to deploy DirectAccess, and IT administrator can use the Getting Started Wizard to configure DirectAccess in a few easy steps. For more complex deployment scenarios, PKI is still required.
It would help if you can present some graphical representations of your problems 'cause every response to your question would only be assumptions.
Troubleshoot as follows:
Check to make sure the windows client is an Enterprise edition
If point 1 above is true, run the 'get-DaConnectionstatus' command on Powershell to see if the client can determine its location, otherwise get a windows enterprise edition.
3.If both point 1 and 2 are true then check to make sure your group policies are well configured. Remember to separate the security groups for windows 7 and windows 8 clients.
I am new to SSL，here I have a question about how to set up SSL/certificate.
Our web site is hosted on server A(Windows server 2003 with IIS6), we also have a WCF web service that is used by the web site to get data from database, and this service is hosted on Server B(Windows server 2003 with IIS6).
So how to setup SSL/Certificate to make sure that the client server communication is encrypted? do I need to apply 2 certificate for each server?
I also have a very fundamental question, say my server's ip address is 192.168.0.5, it has multiple ports for different application, for example 8090, so which one is called domain? 192.168.0.5? or 192.168.0.5.8090?
Thanks
Since both server are running IIS 6, you can just export your certificate as PFX and install it on the other server.
Following sites might be helpful:
Export:
https://support.globalsign.com/customer/portal/articles/1231880-back-up-certificate---internet-information-services-iis-7
http://www.sslshopper.com/move-or-copy-an-ssl-certificate-from-a-windows-server-to-another-windows-server.html
Installation:
https://support.globalsign.com/customer/portal/articles/1290320-install-certificate---internet-information-services-iis-5-6
http://www.sslshopper.com/microsoft-iis-5-and-6-ssl-installation-instructions.html
Hope this helps!
I suddenly started getting this error when trying to connect to any of my sql servers (25+) from SSMS on Windows XP. When I left work yesterday everything was working fine, came in this morning, and I started getting this. Tried rebooting my pc but that obviously didn't fix it. My co-workers can all connect just fine. Searched for a solution but everything I found was regarding encryption in regards to .NET applications. Not sure how to apply that to SSMS.
alt text http://picasaweb.google.com/lh/photo/-l9VrFuYXk-A80NzZ1kzng?feat=directlink
For some reason the image won't work so the error is this:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.) (Microsoft SQL Server)
The question seems to have been answered, but I wanted to chime in. For some providers, such as SQL Server, there is a parameter in connection string which lets you connect to server encrypted even if certificate is unknown: "TrustServerCertificate=True", so if you include that in a connection string, you will connect and work encrypted, and will not have to run connection non-encrypted.
Try this...
Its gotta be a client issue if you lost connection to all your remote servers and your coworkers are fine. You probably got "clicky" and changed some settings inadvertantly.
Open your client network utility (mine is here: C:\WINDOWS\system32\cliconfg.exe).
Under the General Tab, check out the disabled protocols. They should all have "force protocol encryption" unchecked. If this is checked for any of those values, your local SSMS is probably trying to force an encrypted connection and failing.
Report back if this doesn't work, and I'll poke around a bit more.
When connecting using MS SQL Server Management Studio in the connect window go to Options->Connection Properties and check checkbox Trust server certificate
You connect to your SQL Servers requesting encrypted connections and you don't trust the certificate(s) used by those servers. Why that happens depends on a myriad or reasons.
Do your servers use self-signed certificates or PKI issued certificates?
Who is the PKI authorithy that issued your certificates? Is it a corporate certificate service?
Does your computer trust the PKI root authority?
If you don't know the answers to this, you must contact your network and security administrators. Simply disabling protocl enforcing requirement from your client may be against corporate policy, or the servers may enforce SSL anyway disregarding your local setting.
These are all questions you should ask your own environment admins, not public forums. You should try to solve the issue, not hack your way arround it and end up with a non-compliant machine.
From this link:
Disable client-side Force Encryption
on the server. On the machine that
runs the SQL Server instance, open up
the SQL Server Configuration Manager,
right-click SQL Native Client
Configuration, and set Force Protocol
Encryption to No. Then try connecting
locally.
http://blogs.msdn.com/sql_protocols/archive/2005/12/22/506607.aspx
I got this error, I tried to connect a remote server SQL (SaaS) in MS Cloud
I added a new firewall rule in Azure portal with my client IP that solved my issue
Open Command Prompt: press Windows Key+ R then type cmd and run
Enter this:
runas /user:[YourDomainName]\[YourActiveDirectoryUserName] /netonly cmd
Enter your active directory password and press enter
In New Command Window enter your SSMS.exe Path with double cotation like:
"C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\ManagementStudio\Ssms.exe"
Then login with windows athentication