Konnectd with ldaps fails verification but no setting for allowing.

EtherMan

I want konnectd as a provider, with ldap backend. It’s the same ldap that kc itself uses, but less points of failures if konnectd uses ldap directly, hence that choice. However, looking through the config file, I find no way of specifying any tls settings for the ldap backend. (not the kc backend either for that matter but don’t need that). When trying to connect to the backend it fails with “level=error msg=“identifier failed to logon with backend” error=“ldap identifier backend logon connect error: LDAP Result Code 200 “Network Error”: tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config””, but I don’t have any tls.Config, nor do I find any information on a tls.Config for konnectd. I’d imagine this error is due to it being my own CA, but don’t really have a choice in that matter seeing as how openldap accepts all client certs signed by the same CA so using letsencrypt on openldap, would allow anyone with a letsencrypt cert, which is clearly not a good situation. And I also don’t want to allow non tls connections to the ldap server, so I must have it verify this properly. But how? Is tls.Config even a file or a var in another file? While being able to pass a client cert is not critical at this point, would that be possible using konnectd as well with these tls settings?

fbartels

Hi @EtherMan,

if you would be using line breaks your posts would be easier to read.

In case you want to use tokens generated by Konnect to log into the Kopano backend (e.g. through our rest api or webapp) then you currently need to use the Kopano backend of Konnect and cannot use the ldap backend.

EtherMan

Eh? Why? That kind of defeats one of the purposes of OpenID as a system then if every service needed to have the provider use their specific backend. I would have figured it would just be a matter of matching up the fields of the token to the fields that Kopano expects them to be in.

And sorry about the line breaks. Didn’t realize it was that long :)

fbartels

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

Eh? Why?

Because it is how it’s currently implemented. A similar question came up in the part already: https://forum.kopano.io/topic/2563/webapp-konnect-with-ldap-backend/11

It’s not like every service needs their own provider, you should be freely able to log into any other applications with the Kopano backend, but to also access the Kopano data it’s more convenient to also use the Kopano backend.

And if you already have an openid provider, then you could even use this as an external provider for Konnect.

EtherMan

I saw that but it doesn’t say anything about it being impossible. Quite the contrary as it seems to be a relatively minor thing to strip “uid=” from the token before passing to login in KC.

And you say if I already have an openid provider, then I could use that in konnect… How would I do that if konnect requires the backend to be KC? Why is ldap even an option available to set in Konnectd if it’s not actually usable? I don’t get it :/

But still, even if I use KC as the backend, that doesn’t really solve the question here, since I still can’t find any configuration for TLS. Neither for Konnect to verify the identity of the server, or for providing a cert so as to authenticate the client.

fbartels

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

How would I do that if konnect requires the backend to be KC?

The external auth does not influence the backend used in Konnect. The backend is still required to look up the user and map the user between the external provider and the backend.

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

Why is ldap even an option available to set in Konnectd if it’s not actually usable?

If is usable on its own. You can use Konnect and e.g. Kopano Meet completely independend of the Kopano backend.

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

still can’t find any configuration for TLS. Neither for Konnect to verify the identity of the server, or for providing a cert so as to authenticate the client.

I don’t fully get what you are asking here. The identify of the server would be verified through the chain of the cert. The ca needs to be trusted by your host and then connection should succeed. Why do you think you need the use a client cert here?

If you have Konnect running on a different host and need to establish a session in the Kopano backend, then this is configured with the KOPANO_CLIENT_CERTIFICATE and KOPANO_CLIENT_PRIVATE_KEY. This is explained more in depth in https://github.com/kopano-dev/konnect#kopano-groupware-storage-server-backend.

EtherMan

The external auth does not influence the backend used in Konnect. The backend is still required to look up the user and map the user between the external provider and the backend.

I see. So that’s a no it’s not possible then.

If is usable on its own. You can use Konnect and e.g. Kopano Meet completely independend of the Kopano backend.

So kopano meet properly implements oid… But kopano server does not. That server does not starts to make even LESS sense now.

I don’t fully get what you are asking here. The identify of the server would be verified through the chain of the cert. The ca needs to be trusted by your host and then connection should succeed. Why do you think you need the use a client cert here?

There is no such thing as having the CA trusted by the host like that on linux systems. There is no unified CA store for linux and each system has their completely own ways of handling it. Go based apps using Go’s native libraries as an example look in dirs based on the dist being used, such as Debian based go in /etc/ssl/certs, while on rhel based it looks in /etc/pki/tls/certs. NSS based apps (Firefox, Thunderbird, Chromium and so on) use trust store databases in the user’s home dirs that you now have to insert the cert into (which is more than just placing a file in a dir). Java based apps again use a truststore, but its own format and so on… So saying that the CA needs to be trusted by the system, is a nonsensical statement. It needs to be trusted by WHICH system here?

And let’s assume I add it to this as of yet unknown system… That doesn’t allow me to verify the proper identity of the server. That may have been fine in a time where SSL certs were expensive and hard to get with high levels of verification for them. It’s not fine in a world where everyone has free access to certs issued by a trusted root, such as letsencrypt. Because if Konnect now fully trusts any server it connects to as long as it has the right CA, then Konnect will happily send out authentication details to that server, despite never having verified that this is ACTUALLY the server I want to be sending this to. That requires actually specifying the CA you want to check for.

I thank you for the link regarding client certs for kopano though.

longsleep

@EtherMan I think i can share some additional details on the questions / issues discussed here.

1. The relation of OpenID Connect and the Kopano Core backend (kc)

There seems to be some confusion as of the OIDC usage of Kopano Groupware Core together with tokens.

Konnect issues standard OpenID Connect ID Tokens, any OIDC relying party can use those for identity.

Konnect also issues OpenID Access tokens. As are opaque from the OIDC relying party perspective, they are can only be used to access the user info endpoint of the corresponding OIDC identity provider.

When used together with Kopano Groupware, the access tokens gain additional features and are no longer opaque and are interpreted by the Kopano Groupware MAPI client for additional user related information. With Konnect, the access tokens are also JSON Web Tokens and based on the Konnect configuration, the access tokens hold clains which are later required by the Kopano Groupware MAPI stack. This is done to simplify the setup since within Kopano we simply have a single access token. So in that sense, Konnect and any Kopano Groupware component form the OIDC relying party together (while Konnect additionally also provides the OIDC IdP to itself, and also potentially others).

When using the LDAP backend of Konnect, the additional Kopano Groupware claims in the access token are not provided and thus any Groupware client requiring them fails to work.

We might do something to relax this relation in the future, but this setup works quite well and serves our purpose just fine.

For use cases where for whatever reason Konnect shall use another backend, the current recommended approach is to simply have another Konnect set up (for example with the LDAP backend) which is used by the Kopano Groupware aware Konnect as external authority (like mentioned by @fbartels above).

It remains to say that technically all information required for authentication and identity is available in the Konnect access tokens, regardless of the configured backend. So technically a translation is possible on the token consumer side, at the cost of additional lookup or mapping. We have not ventured in that area for now.

2. How the Konnect TLS client configuration works

Konnect uses a global TLS client configuration for all its TLS clients.

This means that all TLS connections use the same rules and checks.

The Konnect specific public exposed parameter for this configuration is the --insecure command line parameter, which allows to turn of TLS certificate validation (for testing purposes, of course do not do this in production).

Additional behavior comes from built in defaults. One of these defaults is the location where Konnect loads its trusted Root CA’s from. As you mentioned, there is no general default “system” location. System use different ones, and Konnect as inherits possible locations from the Go programming language. https://golang.org/src/crypto/x509/root_linux.go defines the locations and the defaults for Linux (loaded by https://golang.org/src/crypto/x509/root_unix.go) and should work good for any current Linux distribution. This is what @fbartels mentioned that our current general suggestion is to get all your potential custom CA’s trusted on your particular system and Konnect will pick it up accordingly.

With this covered, by using a secure CA and together with secure DNS, you can be sure that the connection is made to the desired system and to that system only.

What you ask goes a little further, since you want to exactly specify what certificates Konnect should allow connections to (LDAP, but it goes for everything else). This is currently out of scope of our documentation and i think we could add the above information.

Furthermore, the location of the cert store and (file or dir) can be specified/customized via environment variables.

	// certFileEnv is the environment variable which identifies where to locate
	// the SSL certificate file. If set this overrides the system default.
	"SSL_CERT_FILE"

	// certDirEnv is the environment variable which identifies which directory
	// to check for SSL certificate files. If set this overrides the system default.
	"SSL_CERT_DIR"

This is currently undocumented in Konnect (as it comes from the Go programming language), and i have not tested. So please try and report back if that suites your needs better.

So @EtherMan i am always interested in real world use cases like yours - feel free to share more since feedback like your always has an influence on how Konnect will continue to grow in its flexibility and features.

Please also let me know if something on my above details is unclear :)

EtherMan

@longsleep Thank you for the detailed explanation. That brings a lot of clarity. Especially that Konnect uses Go standard libraries as that then tells me the location for that. Though I must point out that “by using a secure CA and together with secure DNS, you can be sure that the connection is made to the desired system and to that system only.” is in no way true. DNS is inherently open to multiple vulnerabilities and injection attacks happen on a daily basis.

Since I’ll be using containers, I suppose the easiest solution is to mount in the CA as a secret in place of that file such that it only has a single CA in total. Would that work or are there external checks that it has to do that requires one of the standard CAs? There’s the survey service that does, but that can be disabled and I’m unsure if that verifies identity though I assume it does.

longsleep

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

Though I must point out that “by using a secure CA and together with secure DNS, you can be sure that the connection is made to the desired system and to that system only.” is in no way true. DNS is inherently open to multiple vulnerabilities and injection attacks happen on a daily basis.

While this is generally the case, it should be a little different in your internal environment where you have full control of all involved resolvers.

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

Since I’ll be using containers, I suppose the easiest solution is to mount in the CA as a secret in place of that file such that it only has a single CA in total. Would that work or are there external checks that it has to do that requires one of the standard CAs?

Yes, that should do it. Generally when using containers, it is recommended to mount the trusted CA’s from a location controlled by the local system. Most containers might not even ship any trusted CA.

@EtherMan said in Konnectd with ldaps fails verification but no setting for allowing.:

There’s the survey service that does, but that can be disabled and I’m unsure if that verifies identity though I assume it does.

The survey client uses the normal default CA list to discover if the connection is trusted. So it is effected by SSL_CERT_FILE and/or SSL_CERT_DIR. Since the survey client or its success is entirely optional, any runtime error it produces is not fatal.