go to post Katherine Reid · Jul 7, 2021 Have you tried specifying the location and name of the SSLDefs.ini file with the ISC_SSLconfigurations environment variable? This is an alternate way of specifying where the configuration file is.
go to post Katherine Reid · May 26, 2021 The two places that I would look for more information on a <PROTECT> error are the audit log and the line of code the error is coming from. The audit entry for a <PROTECT> error sometimes has more information about why the error was generated. The line of code can also help as it can show you whether there was an explicit permission check, a reference to a particular global, etc.
go to post Katherine Reid · May 17, 2021 There isn't support for EC keys in Cache. If you haven't already, you could ask for an enhancement to add support in IRIS. That's a long term solution though. For now, the only solutions I can think of are workarounds like your CPIPE and cURL method or stunnel around %Net.Httprequest.
go to post Katherine Reid · Apr 14, 2021 For <PROTECT> errors, if you turn on auditing of protect errors, the audit log will often have more information about the exact place the error comes from. To do this, you will need to enable auditing system-wide via either the portal or ^SECURITY, make sure that auditing for the specific event you want (protect) is enabled, then reproduce the error. There deliberately isn't much information about which permission is missing given to the user who got the error, to prevent a malicious user from mapping out info about the permissions needed.
go to post Katherine Reid · Mar 25, 2021 Is your concern that the audit log will have extra events that aren't really failures? If the login eventually succeeds, the authentication methods which didn't work should not cause loginfailure audit events. Otherwise, there would be loginfailure events confusing the audit log on any system with more than one type of authentication enabled. If the login fails, all types of authentication which were tried will be logged.
go to post Katherine Reid · Mar 25, 2021 Yes, you must enable an authentication type system-wide before you can use it in an application. An authentication type must be enabled both system-wide and in the individual application or service the login is using to be used. You can turn LDAP off in all other applications if you only want it in the one application. The one which is using LDAP authentication will need to look at the shared system-wide settings about domains, servers, attributes, etc, to know what to do with users logging in. If the users and employees are part of different domains, you might want to look into the multiple domain support. You may be able to use the multiple domain support to let both sets of logins work separately.
go to post Katherine Reid · Dec 9, 2020 If you mean how they're moved in the sense of how does Cache make sure data is durable in the database and consistent even if there's a crash, you might look at the data integrity guide's section on the write image journal (WIJ): https://cedocs.intersystems.com/ens201814/csp/docbook/Doc.View.cls?KEY=G... You might mean a number of other higher-level things though.
go to post Katherine Reid · Nov 18, 2020 Async mirrors are commonly used for reporting and other purposes. What do you want to scale down to use it here?
go to post Katherine Reid · Nov 12, 2020 Mirroring is about creating identical globals on multiple machines with one update. I assume you don't want these systems exactly the same, but depending on what you do want, maybe you could find a configuration which would do it. For example, maybe you could put the global you want replicated in its own database on an async member and not mirror any other databases.
go to post Katherine Reid · Sep 25, 2020 It sounds like you're trying to configure a webgateway on Linux to authenticate to an IRIS server on another machine using Kerberos. Is that right? If so, are you already using Kerberos authentication on the IRIS server for other connections? I would start by making sure Kerberos is working for other connection types first, which will help sort out whether this is a configuration problem on the server side or the Webgateway side. Do you already use Kerberos elsewhere on the Linux server?
