I think you may be looking at the wrong class documentation.
There are two LDAP classes - %Net.LDAP.Client and %SYS.LDAP. The EnsLib.LDAP.OutboundAdapter is written using %Net.LDAP.Client.Session, which does not have a Binds method. The %SYS.LDAP class does have a Binds method, and discusses wanting a $lb like you've described.
There are a couple of things you could be doing here, so let me make sure I understand what you're trying to do. Are you trying to configure LDAP authentication so that users who log into Ensemble will authenticate against the LDAP server, based on the settings in the System Administration > Security > System Settings > LDAP options ?
If so:
What error do you get when you try to log in?
Have you tried the "Test LDAP authentication" option in ^SECURITY? This may give you more details of what's failing. (It's under 12) System parameter setup, then 3) Edit LDAP options )
Are you using the "Use LDAP Groups for Roles/Routine/Namespace" option? I'm guessing not, since you said you added IntersystemsAccount to the schema, but want to check because you also mentioned groups. (You may not have this option on some older versions.)
I agree - that SOP sounds like you have an outside vendor acting as a CA. If you're using a CA vendor that still only supports SHA-1, it may be worth considering looking for a new vendor. Whether an internal or external CA makes sense for you long term can be a complicated question. It's worth having a detailed internal discussion about what your security requirements are and what the risks and benefits of each case are before making that decision.
If you want to look at a PEM-format certificate in order to see who it's signed by, you can run:
openssl x509 -in certificate-to-display.pem -noout -text
where certificate-to-display.pem is the name of the file you want to read. This will display the certificate in a human-readable format. The CA who signed the certificate will be listed in the Issuer field.
You don't need the servermanager.exe anymore. (Anymore includes 2015.1.) Details are here:
https://community.intersystems.com/post/configuring-cach%C3%A9-client-a…
There aren't enough details here for me to guess exactly what's going wrong, but I can suggest some debugging steps that might help make things clearer.
First, if you haven't already, enable auditing and the Protect, Login and LoginFailure events. Then try reproducing this and see whether any audit events were generated. The data in these may make it clearer what's wrong.
Second, I'm not sure how you checked the ^ERRORS global, but if you haven't looked at the "application error log" in the portal (under System Operation > System Logs) I would recommend doing that. That page lets you see all the namespaces with errors logged.
Windows versions of Caché come with a built-in telnet server. If you're running Caché on Windows, you can configure it to run a telnet server just through the system management portal. Caché on other platforms does not have this. On any other platform (such as the Ubuntu mentioned above), you need to install separate software to run a telnet or SSH server.
I would strongly recommend only using the telnet service with Kerberos or SSL. Plain telnet is a huge security risk and should not be used.
On the client side, you will also need a client to connect to the server. The client will need to be able to use the same protocol the server expects. The Caché client tools include a telnet client which supports Kerberized telnet and telnet with SSL. Putty is a telnet and SSH client, but I don't think it has support for telnet with SSL or Kerberized telnet.
I agree that removing the cache.ids is the way to fix this particular problem.
For any others with a similar error, please make sure you verify that no Caché processes are running as any user (not just your own user) before removing the cache.ids. On some versions, removing the cache.ids can allow the instance to start twice on the same machine.
Hopefully this is obvious, but giving the UnknownUser %All is a configuration choice that should only be done on a dev or test machine, not a production one.
This is an interesting question which I don't think I've seen anyone think about before.
If this works, I would expect it to use a client certificate in the Windows certificate store. However, I'm not sure that it would work, or what it would do if there were two client certificates.
If you want a clear answer on this, you might want to open a WRC case.
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.
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?
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
It can be tricky to get the exact form of the username right on a Linux client connecting to a Windows AD server. If you're familiar with using an LDAP browser, you might be able to use one to manually look for the user object you're trying to find, and see what the account name shows up as. That might let you check for any details you might not be exactly matching.
Unfortunately I don't know of a one size fits all solution, since each AD server is set up differently.