All
Accepted answers
Katherine Reid · Jun 18, 2019 go to post

This will connect and works for testing, but for a production configuration you should also edit the configuration so that it checks the server's certificate.  If you don't, the configuration will connect without an error even if someone is pretending to be the server you're trying to connect to.  Since you're setting up TLS, that's probably not what you want.

To do this, change the "Server certificate verification" setting from 'none' to 'require' and then fill in the name of the file which contains the certificate authority (CA) certificate for the server you're connecting to in the "File containing trusted Certificate Authority certificate(s)" field.  The certificate should be in PEM format, and the file may contain multiple certificates if you want to include more than one. 

Katherine Reid · Sep 20, 2019 go to post

Is there a reason you're using shadowing instead of mirroring?  Shadowing is much older and doesn't really receive updates or improvements.  It was also not as good at telling you when there was a problem and the destination was behind or out of date, which means it's harder to know that the backup server is ok.

Katherine Reid · May 25, 2016 go to post

I want to second Ben's advice to contact the WRC.  

I also want to add, for anyone reading this later, that moving the CACHE.WIJ file (as suggested in the error above) is an extremely dangerous operation.  Please don't ever do this without contacting the WRC.  Moving the WIJ can lead to data integrity problems which may or may not be obvious.  There are almost always other ways to start the system.

Katherine Reid · Nov 8, 2016 go to post

Aline has a good description of why this happens.  I wanted to say what it means, in case the effects are not obvious.  

This error means that your database isn't transactionally consistent.  Transactions have several properties.  One is that  either none or all of their updates will happen.  Another is that no one will be able to see a situation where some, but not all, of the updates have been completed.  This error is saying that a process was able to change part of these updates while the transaction was being worked on, and therefore we weren't able to safely return to having none of the updates happen.  

 To put this in an example:  pretend you're doing a bank transfer.  You're taking $100 from account A and putting it in account B.  You don't want the $100 to disappear (be removed from A and not added to B) or an extra $100 to be generated (not be removed from A and be added to B.)  This error is saying that one of those situations where money was created or destroyed probably happened.

To prevent this in the future, you'd want to look into whether there are missing locks in the code the processes involved are running.

Katherine Reid · Dec 5, 2016 go to post

There's no built-in functionality to use the IP address as the username in Caché 2016.1 or 2016.2.  (I don't remember there being any way to do this in Caché 5.0 either, but maybe I just never looked.)

You might be able to implement something similar using delegated authentication, but I don't think it's a good idea.  Why do you want IP-based usernames?  It seems like this would be fragile and could break if there are network reconfigurations.

Katherine Reid · Dec 8, 2016 go to post

It sounds like your user may have a login routine defined in their profile. If that's the case, and you exit the routine, the login will exit. It's a similar idea to a Unix captive account.

If you don't have a login routine in the user profile or aren't exiting the routine, can you give more details about exactly what's happening? Is this all users? Some? Does it happen when you switch to all namespaces or just some?

Katherine Reid · Jan 4, 2017 go to post

This error is most often due to the TCP connection going away without the adaptor realizing it.  If the problem is a network issue, the error may go away once that's resolved.  If StayConnected is set to a large value (or -1), it may also help to set it to a small, positive value (such as 5 or 10).  This value controls how many seconds of idle time the adaptor allows.  If it's currently higher than one of the TCP timeouts in your connection, that could account for the error.

Katherine Reid · Jan 30, 2017 go to post

That error probably means there's a problem on the TCP level or with the SSL handshake, not in the SOAP request.  I'd recommend doing:

%SYS> d ^REDEBUG

and setting the value to FFFFFFFF, then reproducing the problem.  This will log information which should help in the cconsole.log.  

Remember to run the utility again to set the debug level back to FF once you're done, since the higher debugging level puts a lot of entries into the log.

Katherine Reid · Feb 8, 2017 go to post

That error looks like the CSP gateway can't log in to the Cache instance.  The CSP gateway needs to log in in order to serve the portal login page to you.  Given that you disabled all the other users, I'd guess you've disabled the user the CSP gateway is trying to log in as.  

You can figure out which user this is by enabling auditing of LoginFailure events, then trying to load the page again, and checking the audit log to see which user failed to log in.  (All of this can be done with ^SECURITY.)  Alternatively, the most likely user for the gateway to be running as is CSPSystem, so you could try enabling that user and see if it fixes the problem.

Katherine Reid · Mar 2, 2017 go to post

SSL support in Healthshare uses the OpenSSL library.  Which version of the library you have will depend on your exact maintenance kit.  For example: 2016.1.0 has openssl 1.0.1p, 2016.1.1 has 1.0.1t, and 2016.1.2 has 1.0.2h.

You can see which ciphers your version supports by running the following command in the bin directory of your install:

./openssl ciphers ALL

On my install of 2016.1.0 the first cipher listed when I do this is ECDHE-RSA-AES256-GCM-SHA384, which is on your list of preferred ciphers.

If adding less secure ciphers to the list in Healthshare is making your connection work, then I suspect the problem is in the ciphers the other side supports.  You could try to confirm or deny this by looking at the SSL handshake with a tool like Wireshark.

Katherine Reid · Mar 31, 2017 go to post

Writing your own authentication code using the %SYS.LDAP class is independent of the LDAP authentication settings in the portal, yes.

%SYS.LDAP.Binds is the correct authentication method only if you're coming from a Windows machine (and going to a Windows AD server, which you said you are.)  If you're running Cache on Linux or any other non-Windows OS, you should use SimpleBinds instead.

The arguments to Binds aren't quite as you've listed them - I'd recommend looking at the class documentation on them.  I'd also recommend using the StartTLSs method first, to protect the user's credentials.

Katherine Reid · May 1, 2017 go to post

I'm worried that you may be conflating several ideas here.   You said you need to sign your partner's certificate to do mutual authentication.  That's not required technically.  (Maybe it is required by policy for your particular organizations, but I didn't see you say that so I suspect it's not.)

A CA is a trusted party for verifying identities, usually a third party.  You don't need to sign your partner's certificates yourself to do mutual authentication.  That's the power of using a CA - you don't have to do identity verification and issue certificates for every possible connection partner, you trust the CA to do it for you.   

To use an analogy, if a certificate is a driver's license, then the CA is the state agency that issues licenses.  If you operate a service where you need to check identities of people, you don't need to start issuing your own licenses, you can just trust ones issued by states that you think 1) do a good job checking identities before giving out licenses and 2) you recognize and know how to tell if they're real.

To do mutual authentication, you need to have a certificate, and the other side needs to have a certificate.  Both certificates need to be signed by CAs the other side trusts - meaning your certificate needs to be signed by a CA that your partner trusts, and their certificate needs to be signed by a CA you trust.  

You can (and probably should) get your certificates for use in TLS connections with Ensemble/HealthShare through whatever processes you normally use for generating certificates.  

Katherine Reid · May 18, 2017 go to post

What you're describing is moving the location of an instance after installation.  It's not supported.  I've seen people do some pretty bad things to their systems by trying it, and would strongly recommend against it.  

You will need to either run the installer in the new path, or keep the paths the same.

Katherine Reid · Nov 6, 2017 go to post

How would you secure and authenticate network access to the key?  This seems like a question you would want to have a reasonable answer for before considering sending a key over the network.

You might also want to look at the features in InterSystems IRIS data platform.  KMIP support was announced as one of the features in it.

Katherine Reid · Nov 7, 2017 go to post

Using StartTLS (explicit mode) is the default for %Net.FtpSession.   (If you wanted to, you could turn explicit mode off by setting the LegacySSL parameter.)

Have you looked at the connection attempts with a network trace to see what's actually happening?  You might also find useful information by setting the network debug flags to FFFFFFFF via ^REDEBUG in the %SYS namespace, trying a connection, and checking the cconsole.log for information about the SSL configuration which was invoked.  

Katherine Reid · Dec 27, 2017 go to post

I would suggest you contact the WRC about these questions.  

I usually find that connections may be delayed but do succeed after the "Failure Event: -37 - Unable to exchange encryption keys" messages, so I suspect there may be another issue here.

Katherine Reid · Jan 4, 2018 go to post

The %Net.SSH.Session.SetTraceMask method tells a process to collect information about an SSH handshake and connection in a text file, which is useful for debugging SSH connections.  It is information about what the local process is doing and does not include network trace information, such as would be in a WireShark pcap file.  

If you're trying to collect information about an SFTP connection problem, you can use the same SetTraceMethod for the SSH session associated with your FTP connection to collect information.

If you're trying to collect information about an FTPS connection (meaning SSL is in use, not SSH), you can use the ^REDEBUG utility to log information about the SSL handshake to the cconsole.log.  You can enable the REDEBUG flags by running:

Do INTSET^REDEBUG("FFFFFFFF")

in the %SYS namespace.  Remember to set the flags back to "FF" when you're done testing, as the higher log level can generate a lot of data.

If you're trying to debug an un-secured FTP connection or these don't provide the information you want, you may need to use a network trace tool such as Wireshark.

Katherine Reid · Feb 12, 2018 go to post

With delegated logins, you need to return an array from ZAUTHENTICATE with all the properties you want the user to have, including their roles.   This happens during login; you can't change the roles once login is over.  The array used is Properties.  To set the roles in this array, you would do something similar to:

set Properties("Roles")="ACustomRole" 

This would set this user to have the role named ACustomRole.  

Your code gets to decide what that roles are, and can do it based on the group you retrieved.    For example, If you have a group named CacheAdmin and you want all members of that to get the %Manager role, you could do something like

if group="CacheAdmin" {set Properties("Roles")="%Manager"}

(Note that this code makes many assumptions that may not be true for you, such as that you want to overwrite Properties("Roles") instead of adding to it, and the name of the variable you're holding the group name in.)

If you want to add more than one role, you can use a comma separated string, such as "%Manager,ACustomRole"

Katherine Reid · Mar 20, 2018 go to post

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.

Katherine Reid · Apr 11, 2018 go to post

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)
 

Katherine Reid · Jul 11, 2018 go to post

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. 

Katherine Reid · Jan 22, 2019 go to post

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

Katherine Reid · Feb 12, 2019 go to post

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?

Katherine Reid · Feb 19, 2019 go to post

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.

Katherine Reid · Mar 12, 2019 go to post

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

Katherine Reid · May 2, 2019 go to post

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é."

Katherine Reid · May 6, 2019 go to post

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?

Katherine Reid · May 7, 2019 go to post

There are a lot of possible reasons this search be failing, but they mostly boil down to not looking in the right place for the user or not being able to identify the user when you find it.  Here are a few things to try:

For a Windows AD server, you will almost certainly want sAMAccountName as the unique search attribute. 

Check to make sure your base DN includes the location of the user you're trying to authenticate.  You may want to test with a high-level or generic base DN to make sure it matches the user account.  For example, try DC=intersystems, DC=com instead of a longer base DN like: OU=Boston, OU=Users, DC=intersystems, DC=com  This will mean you search a larger part of the tree (which is slower) but will let you make sure you're searching an area which includes your user.

Take a look at exactly what DN the is being used for the failing user.  This should be in the detailed output of the test connection.  Is the base DN being appended to the full DN that you gave as the username?  If so, you may not want to use the full DN as the username, and instead just the value of the account name.

Katherine Reid · Jun 14, 2019 go to post

Are you trying to have the same user have different login namespaces on different systems?  If so, for your InterSystems IRIS instances, have you looked at the "Authorization group ID" and "Authorization Instance ID" which are part of each LDAP configuration?   You can use these to make each instance (or group of instances) look for a different group to define the namespace.