I have upgraded AAD Connect to the latest version and made the registry changes according to https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement, but is there a way to validate that I am actually using TLS 1.2?
I was able to do a network capture and validate that just TLSv1.2 is being used.
Related
This is for a Oracle database standalone server running 12c 12.2.0.1 on windows server 2016.
We are hardening our system and one of the findings was to remove support of SSL and implement TLS 1.2 and upwards where possible. A pen test report found certain port was currently using vulnerable protocols. On investigation i found this to be oracle listener. From research, it seems using Net manager we can configure SSL certificates so that the server to client communications on Oracle are encrypted. The only trouble i'm having right now is finding out any oracle document which will tell me exactly what encryption methods are supported? does anyone know how what is supported? I would like to basically disable support for SSL v2 and v3 through windows registry on all machines and allow only TLS 1.2 or higher but this may break the oracle database 12c comminications i suppose if there is no support for TLS 1.2 or higher? Any help would be appreciated in conjuction with what are the best practices for oracle standalone servers when it comes to security?
Also, a bit of a basic question i guess but in Net manager there are two tabs. One is called Encryption and another called SSL? I understand SSL would mean creating certificates and having them on the client and server such that the messages can be de-crypted. However, what does the Encryption tab do? does it literally just encrypt all communications between server and client but not using SSL or TLS?
Thank you for any help.
Check out the 2 Day DBA + Security Guide for info on network encryption. By default Oracle uses "native" encryption libraries that don't use SSL at all (those are managed by the "Encryption" tab you mentioned). SSL encryption (under the "SSL" tab) uses an entirely different protocol, and requires a specially configured listener, a different network port, and certificates in an Oracle Wallet. Check out the docs; they should walk you through everything. It's certainly too big a subject to tackle completely here.
I have WS 2016 running as AD/DC on which NTLM/NTLMv2 is disabled (Kerberos is a way to go). I have successfully joined Ubuntu machine to it, using this tutorial "Integrate Ubuntu with AD". Everything if working correctly (except Samba), can view users and groups on AD and can login to Ubuntu machine using AD user.
Now when I try to login with AD user to samba share I get NT_STATUS_NTLM_BLOCKED, which is expected, sense NTLM is blocked by AD.
Now my question is how to setup (force) Samba to use kerberos instead NTLM ?
It sounds like you're thinking that the SMB server just receives your password and then uses either NTLM or Kerberos to validate it. That's not how it works.
In SMB, it's the client which speaks NTLM or Kerberos when connecting to the server. You cannot force the server to use Kerberos because that is not the server's decision; it can either offer Kerberos or not, but it cannot make the client support Kerberos if the client doesn't support it.
Most mobile SMB client libraries do not have any Kerberos support (due to complexity); they will only use NTLM.
My "solution" to this issue was simply to exclude specific server from NTLM restriction policy.
There are two policies, on active directory server, in "Local Group Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/Security options":
Network security: Restrict NTLM: Add server exceptions in this domain
Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
So servers that are defined under those two policies are able to use NTLM.
Not a solution, but for now it's a workaround.
I have setup my own mongoDB and enabled authorization that’s hosted on an external server.
Which i can now connect to my DB using mongo Compass while mongoDB is:
bindIp : 0.0.0.0
But not any other things else.
Then I found this thread on the mongoDB community forum:
here
Stating that there’s a misconception on bindIp. Which it does not listen to remote ip that wants to connect, but listen to only local network. In order to connect to my mongoDB with a remote ip while not opening all my port to public (0.0.0.0) i need to set up a SSL connection.
Now here’s the problem. How do i setup SSL connection ? I took the class M301 and know about X.509 but still have no clue how to connect via SSL.
I would like to connect through something like with the connection string of:
mongod://:#XXX.XX.XX.XXX:XXXXX/?ssl=true <<<<
If X.509 is the method, how do i work with pem key ? how do i sign one ? how do i use client key in mongo compass?
If you have a certificate, MongoDB documentation provides guides for setting up TLS on the server. How to create the certificate is usually not covered; typically you would either work for a company whose IT department would take care of this for you, or you would use a service such as MongoDB Atlas which would handle TLS termination.
For learning purposes you can use self-signed certificates and there is probably a university course for setting up TLS.
We are deploying a java application to RHEL 7.5, this java application need connect to SQL Server 2016. As security request, we must use integrated security to connect SQL Server 2016. Follow Microsoft website's suggestion, we are implementing Kerberos in Windows AD Server and RHEL 7.5.
Unfortunately, we are facing a credentials issue. klist command is working fine on RHEL 7.5, means Kerberos clinet which has installed in RHEL7.5 can talk to Kerberos Server(Windows AD server) as normal. And RHEL7.5 can ping / talnet AD Server and SQL Server.
we have followed Microsoft's spec to set SPN as following:
setspn -A HTTP/SERVER_01.devdc.local#DEVDC.LOCAL devdc.local\admin.
As microsoft's guideline, we should use MSSQLSvc not HTTP, but it has issue when we use MSSQLSvc, we think the reason is OS version of AD server is Windows Server 2012, so cannot support MSSQLSvc protocal. After change to HTTP, kerberos is working fine. Can use kinit generate ticket and use klist to see the ticket information.
Part of our Java code as below:
System.setProperty("java.security.krb5.conf", "~/krb5.conf");
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("192.168.100.150");
ds.setPortNumber(1234);
ds.setIntegratedSecurity(true);
ds.setAuthenticationScheme("JavaKerberos");
ds.setDatabaseName("DB_TEST");
The error details as following:
Error connection to database:(using class com.microsoft.sqlserver.jdbc.SQLServerDriver)
GSSException: No valid credentials provide (mechanism level: Server not found)
KrbException: Server not found in Kerberos database(7)
KrbException: Identifier doesn't match expected value(906)
I would be grateful if you can help.
You don't appear to be setting the SPN. See
A service principal name (SPN) is the name by which a client uniquely
identifies an instance of a service.
You can specify the SPN using the serverSpn connection property, or
simply let the driver build it for you (the default). This property is
in the form of: "MSSQLSvc/fqdn:port#REALM" where fqdn is the
fully-qualified domain name, port is the port number, and REALM is the
Kerberos realm of the SQL Server in upper-case letters. The realm
portion of this property is optional if your Kerberos configuration's
default realm is the same realm as that of the Server and is not
included by default. If you wish to support a cross-realm
authentication scenario where the default realm in the Kerberos
configuration is different than the realm of the Server, then you must
set the SPN with the serverSpn property.
For example, your SPN might look like:
"MSSQLSvc/some-server.zzz.corp.contoso.com:1433#ZZZZ.CORP.CONTOSO.COM"
Using Kerberos integrated authentication to connect to SQL Server - Service principal names.
The driver will attempt to build the SPN for you from the other connection attributes, but you've got an IP address instead of a FQDN, so it cannot build the correct SPN. In the default configuration SQL Server registers its own SPNs and you can see the correct SPN in the SQL Server log, but there are scenarios where additional SPNs must be registered for the service account, and you would need to use the setspn command on Windows to see them.
Assuming your SQL Server is listening on port 1234, and you haven't changed the service account for the SQL Server instance from the default, then the SPNs should be registered for the machine accoune, and the setspn statements should be:
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\SERVER_01$
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\SERVER_01$
if you've set a domain account as the service account, say devdc\sqlsvc then substitute that.
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\sqlsvc
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\sqlsvc
TL/DR use the SQL Server's fully-qualified domain name (FQDN) for setServerName() instead of an IP address. If that doesn't work, you'll have to ask your network security people what SPNs are registered for the SQL Server service account. If you give up on Kerberos, fall back to NTLM.
Also in the newer JDBC driver Microsoft has implemented NTLM, which is the other Windows Authentication protocol.
But be aware of the following security caveat:
The NTLM protocol is an old authentication protocol with various
vulnerabilities, which pose a security risk. It's based on a
relatively weak cryptographic scheme and is vulnerable to various
attacks. It's replaced with Kerberos, which is a lot more secure and
recommended. NTLM authentication should only be used in a secure
trusted environment, or when Kerberos can't be used.
The Microsoft JDBC Driver for SQL Server only supports NTLM v2, which
has some security improvements over the original v1 protocol. It's
also recommended to enable Extended Protection, or use SSL Encryption
for increased security.
Using NTLM Authentication to connect to SQL Server - Security risks
I am having to consume a web service via 2 way SSL. We have exchanged certificates and I am trying to connect and am getting a handshake failure. I am using Oracle Service Bus to connect to the web service. My questions:
What is the keystore in the fwmconfig folder (that I access from Oracle Enterprise Manager)?
What is the keystore in the weblogic server (that I access from the admin console/managed server keystore tab)?
What are the differences between these and which one should I use to import the servers cert and try to connect?
Also, there are cacerts in several directories in the installation, what do I use those for?
Not knowing where to import the server certificate. Can someone please help?
The enterprise manager keystore is used by fusion middleware for message level security (encrypting the message with certificates
The weblogic keystore is used by the webserver/load balancer to accept the HTTP requests and handles SSL
See above
The cacerts are the default trusted Root CA's
So the keystore to use for enabling SSL is the weblogic server version.
Also be sure to enable 2 way SSL in weblogic:
http://docs.oracle.com/cd/E14571_01/apirefs.1111/e13952/taskhelp/security/ConfigureTwowaySSL.html
Resources used:
http://theheat.dk/blog/?p=2059