As mentioned earlier, you can use the Security.SSLConfigs class. You'll also want to think about how to deliver the CA certificate. That's needed to verify you're connecting to the right server and not someone impersonating the server. Possibly you could add it to your installer?
If you use Kerberized telnet with encryption, the connection will be encrypted. To quote the documentation:
"Kerberos with Encryption — Kerberos manages initial authentication, ensures the integrity of all communications, and also encrypts all communications. This involves end-to-end encryption for all messages in each direction between the user and Caché."
Are you trying to add TLS (aka SSL) to your connection, or use WS-Security? Which steps to take next depend on which of those you're trying to set up.
If you're trying to add TLS, you'll want to create an SSL/TLS configuration, and use that in the operation. You can find information about these configurations in the documentation. You'll likely also want to read up on certificates in order to understand which files to put in the configuration. It sounds like you already have some certificates (PFX is a certificate format), but I'm not certain whether that is your certificate or the CA certificate for the other side.
The TLS configuration information above assumes your operation is one end of the connection. That's likely since you're sending the data instead of receiving it. If you were receiving it, you'd want to understand whether your webserver was the endpoint.
If you can predict when it's going to happen and enable logging beforehand, SetTraceMask could help. It will log information if the issue is related to the SSH layer. The problem might or might not be in that layer, but it would be good to check. I would use the same 511 flags if you can since we don't know where the problem is yet.
Are you using a version earlier than 2018.1? There was an issue where connections could get interrupted which was fixed in that version. If you're seeing that issue, strace/truss or the similar tool for your OS is the best way to confirm it. You would see the client process get a SIGUSR1 signal right before the connection drops.
The "Error: 20, unable to get local issuer certificate" means you don't have one or more certificates in your server's trusted CA file needed to verify the client's certificate. It looks like the certificate for "/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3" probably isn't in the DigiCertCA.pem file. It's possible that you don't want to trust that CA (and therefore this is being correctly rejected) or that you do want to trust it and that certificate should be added to the file.
Are the other connection attempts you see with empty hostnames for ones where Cache is the server, or the client? I wouldn't be surprised if the hostname isn't displayed when Cache is the server since in that case you don't pass a hostname to the open command.
Have you also enabled SuperServer SSL/TLS? You can do this in the portal at the System Administration > Security > System Security > System-Wide Security settings page.
If that doesn't help, I would recommend running the REDEBUG routine on the server to enable network debugging, then trying the connection from the gateway again. You can turn the network debugging on like this:
%SYS>d ^REDEBUG
Old flag values = FF
New flag values (in Hex): FFFFFFFF
Done
%SYS>
The logging information will be in the cconsole.log file. Remember to set the flags back to FF when you're done to disable collection.
The CSP gateway event log may also be useful. You can access this through the gateway management page. It may be helpful to clear the log, then try the connection again, so that you see only the messages related to your test.
Finally, I see that you've edited the enabled protocols. I would recommend you use the defaults unless you have a specific reason why you need to enable a protocol with known problems, such as SSLv3.
There are two different connections here - one from the browser to the webserver, and one from the CSP gateway to Cache. Either or both can use SSL and they are configured separately.
You said you want HTTPS. This would be used on the connection between the browser and the webserver. It does not involve Cache or the CSP gateway at all. It is configured entirely in the web server configuration. For example, if you are using Apache, it is configured in the httpd.conf and related Apache conf files.
The settings you've shown above are for the CSP gateway to Cache connection. If the gateway and Cache are on separate machines, you may also want to configure SSL for this connection. The gateway will be connecting to the SuperServer on Cache, so you will want to follow the instructions for configuring SuperServer SSL if you want to get this part working. The instructions for that are here:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_C50564
You definitely can do this. These parts of the documentation might be useful. This is on configuring AD group based LDAP authentication:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_LDAP
LDAP authentication is straightforward to set up, but does need specific group names. If you can't do it for some reason, you might want to look at delegated authentication:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_delegated
With delegated, you'll have to write code to handle the authentication and authorization. It can be more flexible, but is also more responsibility.
Either of those options will let your users get permissions based on their AD groups. You'll also need to make the CSP page check for the particular access granted by that role, probably by doing a check for a permission on a resource.
It sounds like you're connecting from a browser to a webpage handled by your mirrorset. If this is the case, then you may want to start debugging the problem with a network trace, such as one collected with Wireshark.
Remember that this TLS connection is between the browser and the webserver. The connection between the web gateway and InterSystems IRIS is a separate connection which will be negotiated separately. Due to this, there aren't any settings inside InterSystems IRIS which will affect the browser to webserver connection.
If this isn't the type of connection you're doing, can you describe where you're connecting from and to?
You might be interested in this page:
https://docs.intersystems.com/ens20181/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_standards
Or potentially some of the documents on this one:
https://www.intersystems.com/gt/
Database encryption uses AES. You select the key size when creating the key; 128, 192, and 256 bits are all options.
If you have a specific question about standards not covered there, I would recommend contacting the WRC.
The link above is to the latest documentation, which means it has the new features in 2018.1. You might want to look at the 2016.1 or 2016.2 documentation to make sure you're getting the right info for your version.
The %Net.HttpRequest property AuthenticationSchemes, which has Negotiate as an option is also new in 2018.1.
Ensemble supports several SSO options, but they generally require you to have an existing framework to use. For example, OpenAM and Kerberos are supported SSO options, but in both cases you would need the frameworks and central servers for them already in place.
You might want to start by figuring out which framework(s) your other applications use already, and then seeing if you can add Ensemble to those, rather than looking at what Ensemble supports and picking based on that.
The answers you've gotten so far are for the management portal, but you also mentioned Studio, and I wanted to follow up on that part, as it's configured quite differently.
Studio connects directly to the SuperServer, so you will need to configure SuperServer TLS on the server side if you haven't already. The documentation discusses how to do this here:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_C51191
Currently, I don't know of a way to enforce TLS for just the %Service_Bindings, so you will need to enforce it on all connections to the SuperServer if you want to require it. This means you'll need to configure TLS for any other types of connections to the SuperServer you use, including between the CSP gateway and the SuperServer.
Each machine which has Studio installed will also need to be configured to use TLS. I've written up how to do that here:
https://community.intersystems.com/post/configuring-cach%C3%A9-client-applications-ssltls
Do you have an example of the calls you're making and the errors you're seeing? I don't understand whats wrong from your description and think an example would help.
I wanted to add that you certainly can create an attribute to list a user's roles as described here, and some sites do, but it's not the only way to configure LDAP authentication.
Many administrators find the group-based behavior enabled by the "Use LDAP Groups for Roles/Routine/Namespace" option easier to configure, so you should consider that option if you're setting up LDAP authentication. If you do use that option, many of the steps here will be different, including at least steps 17-23 where the attribute is created and configured.
Your second call may be overwritting the value in the first. I would suggest setting all values you want set in a single call, with the output going to a single file. For example:
s status=connection.SetTraceMask(511,"/tmp/ssh.log")
Also, double check that you're running this before the connection is made. I usually run it immediately after creating the new %Net.SSH.Session object.
Are you running that command at the programmer prompt, by any chance? It's got a macro defined, and therefore won't work at the command prompt unless you change the macro.
There are a lot of details not included here which could be necessary. For example:
Are you using a custom login page? The "invalid password" message you state should never be returned by default Cache pages. This message would leak information to an attacker by letting them know that they had found a valid username. "Access denied" is the standard message returned by Cache when a login fails, for any reason.
Have you checked the audit log for login and/or loginfailure events? You may need to enable auditing, and then the individual event types, then reproduce the problem. The loginfailure event should give a reason for the failure to log in. Depending on what's happening here, it may not be the same as the error returned to the user.
The format on that public key doesn't look right. OpenSSH format keys usually start with ssh-rsa, then the encoded key. They do not have ascii armor (the -----BEGIN SSH2 PUBLIC KEY----- part.)
OpenSSH format is the correct public key format, so your format should be ok. The private key should be PEM encoded.
I've seen this happen sometimes when the key is in the correct format but the file has extra blank space in it, so I'd recommend making sure the key is all on one line with no white space or line breaks. Whether this should matter is debated, but it's easy to to check.
This error is coming from the libssh2 library, so if you want to research it further, you could look into other people using that library who've seen it.
This is true, and adding the user to the group to stop and start is the right approach. However, I wanted to comment on making users members of the cacheusr group, as this has large security implications on most systems.
There are two groups used in a Cache install: one is the set of users allowed to start and stop the instance, the other is an internal tool for managing file access.
By default, the internal group (the "Effective group for Caché processes") is cacheusr. No real users should be a member of this group. The documentation on this page says: "On a secure system, no actual user should be a member of this group. By default, this group is cacheusr, but you can change the group during installation." A user who is a member of the cacheusr group will generally be able to alter or delete Cache databases, config files, and binaries at the OS level. This is a large ability, and one you may not want to hand to users for their standard logins, and instead reserve for cases where they specifically show they mean to do that.
During install, if you chose any setting other than 'minimal' for your initial security settings, you'll be prompted to pick the group to stop and start the instance. I would recommend picking a group other than cacheuser in order to keep these two functions separate. Then you can add the users who you want to be able to start and stop the instance to this different group. Note that changing this group manually, after install, is not recommended.
Whenever you see a message in the log which makes you think the system may be hung or frozen, such as 'Freezing system', please run the CacheHung command before restarting the instance or OS. This will collect information on how and why the system is hung, and may direct you to take further steps to collect information.
CacheHung is an OS script located in the bin directory under your install directory. On a Linux system, you can run it with a command such as:
bash$ cd /InterSystems/Cache/bin
bash$ ./CacheHung.sh
You'll need to use your own path to the bin directory, of course. There will be several prompts about what to collect, and the script will take a minute or two to run. Depending on your configuration, you may need to be root to run it.
Once the data has been collected, you can open the generated file with a web browser and go to the "self-diagnosis" section to see whether more steps are suggested.
Have you contacted the WRC about this behavior to see whether this is intended? Permissions should not be based on the role name, so your new role should be the same if it has all the same privileges.
I agree with Andrew that this is complex enough that you'll get better answers by talking to the WRC. In addition, I'd also recommend taking a Buttons or CacheHung report quickly, so that you have the cstat data to look at later if the problem clears up. If it clears up before you collect any data, there likely won't be much anyone can say.
There isn't currently a way to avoid running ZAUTHENTICATE before password logins. Running the routine is deliberate behavior because it's used by some sites as part of their login process. You could ask for a change, such as a configuration option to control the behaviour, to be added but that won't fix your issue right now.
Have you considered changing the existing password users to being delegated users? This would remove the extra login failure event for them. You would have to update your ZAUTHENTICATE code to handle the accounts, or create matching accounts on your AD server.
You can change user account types by editing the user objects. Here's an example of how you can do it:
%SYS>s status=##class(Security.Users).Get("Admin",.prop)
%SYS>w prop("Flags") ; This is the property which states this is a password user account
1
%SYS>s prop("Flags")=4 ; This value says this is a delegated user
%SYS>s status=##class(Security.Users).Modify("Admin",.prop)
This isn't one of the errors that easy to diagnose based on the client log, unfortunately. Here are a couple of the most likely things it could be:
- This error can happen when the client and server don't support compatible versions of TLS. For example, if you're configured to use only TLS v1.0 and the server wants TLS v1.2. This is more likely if you're using an older version of Ensemble which doesn't support TLS v1.2. Which versions of SSL/TLS have you enabled? (Note: trying to fix this by enabling all possible versions is a bad idea. SSLv3 should not be used.)
- This could also mean that the server requires server name indication (SNI) and the SNI info is not being sent by your client. SNI is supported in Ensemble 2017.2.
This isn't causing your failure, but I would recommend that you change the value of peer certificate verification from 'none' to 'required'. As a client, you want to check that you're connecting to the server you think you are, not another server pretending to be that one. You will need to set a certificate authority file for this to work.
That error is the generic failure, so it doesn't tell us what's wrong. You can get more information by enabling the network debug flags:
%SYS>d INTSET^REDEBUG("FFFFFFFF")
and then trying again. Detailed errors will be printed in the cconsole.log. This level of debug info can fill the log quickly, so remember to set the level back to "FF" after you're done testing.
Also note that the test button in a configuration can't handle any protocols where there are messages before the TLS handshake. This shouldn't be a problem for https, but it may be an issue for SMTP, FTPS, etc.
What are you trying to do with the keystore? Are you using it as your client certificate for the SSL part of an https connection? If so, you can't use a keystore for this and will have to convert the certificate and key to PEM format. If not, can you give a description of what you're trying to do with it?
The 'troubled' state you're referring to is the state listed in the portal's system dashboard, correct?
This is likely to be due to the write daemon not completing a pass in a timely fashion. I'd start by checking the cconsole.log for any messages about the write daemon.
This currently works, but breaks the class abstraction, so it might stop working without warning if the implementation of the class changes. If you can use the documented queries or methods in the Security.Roles class, I would recommend that instead.