Add the capability for the LDAP and AD realms to bind using Kerberos credentials #41126

bizybot · 2019-04-11T18:07:39Z

This commit adds support for LDAP bind using SASL-GSSAPI as an
alternative to simple bind.

new configuration setting bind_mode with value sasl_gssapi will
enable LDAP bind using GSSAPI. Defaults to simple bind.
GSSAPI bind can use either a keytab or a password.
Actual authentication to LDAP realm would not use GSSAPI.

Testing is done by enabling SASL on OpenLDAP and mapping a user
from Kerberos(mapped to bind DN) in a dockerized environment.
Verified the GSSAPI bind happens either using keytab or credentials.

Closes #39878

bizybot · 2019-04-11T18:30:26Z

@elasticmachine run elasticsearch-ci/1

…ocally it is running fine

elasticmachine · 2019-04-12T08:30:33Z

Pinging @elastic/es-security

bizybot · 2019-04-15T01:29:04Z

@elasticmachine run elasticsearch-ci/packaging-sample

bizybot · 2019-04-15T02:55:58Z

unrelated failure
@elasticmachine run elasticsearch-ci/1

albertzaharovits

This looks solid in the test department! Nice job 👍
I have left a few comments around simplifying realm configuration, that will have repercussions on BindRequestBuilder as well.
I still have to grok the tests, but I will do that in a follow-up.

...ain/java/org/elasticsearch/xpack/core/security/authc/ldap/PoolingSessionFactorySettings.java

albertzaharovits · 2019-04-17T12:07:01Z

...ain/java/org/elasticsearch/xpack/core/security/authc/ldap/PoolingSessionFactorySettings.java

+                default:
+                    throw new IllegalArgumentException("only [simple] and [sasl_gssapi] bind mode are allowed, [" + v + "] is invalid");
+                }
+            }, Setting.Property.NodeScope));


I like the switch validation !
But, can't we infer the mode from if SASL_GSSAPI_PRINCIPAL is present. SASL_GSSAPI_PRINCIPAL cannot be null in the way we use the library, right? Also, using SASL_GSSAPI_PRINCIPAL together with a BIND_DN should trigger a settings validation error.

Right now other than simple and sasl_gssapi we do not wish to support other bind types but there are other bind types via SASL that the LDAP has support for. So relying on the presence of SASL_GSSAPI_PRINCIPAL or SASL_GSSAPI_KEYTAB_PATH is something I would like to avoid.

Right now it gets ignored but I agree to throw settings validation error in presence of both BIND_DN and SASL_GSSAPI_PRINCIPAL settings. I will make these changes. Thank you.

Wouldn't other bind methods not also have their setting keys namespaced similarly to sasl_gssapi ? So there would be no ambiguity? To me this is a case of namespaced settings versus conditional settings, as in #30241 . The conditional setting is harder to validate in the code, compared to the namespaced ones, because the validation of the namespaced ones is just to get the whole namespace and validate them as a group. It's also simpler from a user perspective, because he has fewer settings to worry about.

This is just an opinion, do as you think, or ask for other's opinions.

...ain/java/org/elasticsearch/xpack/core/security/authc/ldap/PoolingSessionFactorySettings.java

albertzaharovits · 2019-04-17T12:29:54Z

x-pack/plugin/core/src/main/plugin-metadata/plugin-security.policy

+  permission java.util.PropertyPermission "java.security.debug","write";
+
+  permission javax.security.auth.AuthPermission "createLoginContext.GSSAPIBindRequest";
+  permission javax.security.auth.AuthPermission "setLoginConfiguration";


can't these be moved to x-pack/plugin/security/src/main/plugin-metadata/plugin-security.policy ?

No, as unboundid dependencies are in the core we need to have these here. Thank you.

I think these are a lot of obscure permissions we're granting for any plugin (that inherits x-pack-plugin-core). I worry especially about the maintainability. In this case I think we should move the unboundid dependency over to the security plugin. I think it should not have been a dependecy in plugin-core in the first place. The only imported class from that dependecy in plugin-core is an enum, LdapSearchScope, which I think we should emulate our own and use that in plugin-core and adapt the APIs.

What do you think?

++ on moving the dependencies and getting the permissions in one place, though I see a TODO which I think is a non-trivial change and would require considerable thought as I am not much aware of what needs to be done here.
https://github.com/elastic/elasticsearch/blob/73bfdc4066be080dc4cad1f0521bf6ea14cded93/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/XPackPlugin.java#L95..L124

I think I will pick this up later as a cleanup task. Thank you.

albertzaharovits · 2019-04-17T12:36:57Z

I believe enhancements shouldn't go in patch releases.

albertzaharovits · 2019-04-17T12:42:06Z

And another suggestion: I would change the PR title.
The PR adds the capability for the LDAP and AD realms to bind using Kerberos credentials.
IMO, SASL and his friend GSSAPI are too low level details for the title.

albertzaharovits · 2019-04-24T10:38:35Z

...urity/src/main/java/org/elasticsearch/xpack/security/authc/ldap/bind/BindRequestBuilder.java

+        return bindRequest;
+    }
+
+    private Path validateGSSAPISettings(final byte[] bindPassword) {


Call me hypercritical, but this is woefully complex. And it all stems from that conditional setting I'm gripping about...

What I don't lilke:
This class can deduce the SASL principal, if it needs to, but it cannot deduce the bind DN. So, in case it needs the bind DN, it will use the provided function for that. But the caller needs to know when the bind DN is required, so that it can pass the function. This requires for the caller to know of the internals of the BindRequestBuilder which is a violation of the abstraction.

I suggest we create a separate BindRequestBuilder for the SASL case only, and have the caller (or another wrapper) handle the decision of which BindRequest type to build, given the realm settings.

albertzaharovits

I had another pass and I'll admit I am opinionated on the setting topic and I would like to have someone else opinion on it. Besides that, I would also like to move the JVM permissions (and unboundid dependency) inside the security plugin and away from the plugin-core.

albertzaharovits · 2019-04-24T11:33:28Z

Thank you for the iterations Yogesh!

bizybot · 2019-05-01T07:47:39Z

@elasticmachine run elasticsearch-ci/1

tvernum · 2019-10-31T04:25:05Z

This PR is stale and we are not planning to proceed with it at this time.

WIP: Add support for LDAP bind using SASL GSS-API

cd80858

Yogesh Gaikwad added 7 commits April 12, 2019 12:24

remove image tag during build, not sure if this will fix the build, l…

42ff127

…ocally it is running fine

add healthcheck for kdc-kadmin

230bc87

create temp file so it can be mounted

33dbb09

correct the file name

d3be59f

another file

20cbecd

things not working on CI, debug

e29cf26

remove unrelated changes

7332792

colings86 added the :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) label Apr 12, 2019

Yogesh Gaikwad added 2 commits April 12, 2019 19:17

explicit volumes docker, see if it works

26ae7da

we are running as root inside container, give permissions

955469e

bizybot changed the title ~~WIP: Add support for LDAP bind using SASL GSS-API~~ WIP: Add support for LDAP bind using SASL GSSAPI Apr 12, 2019

bizybot added v6.7.2 v7.2.0 v8.0.0 v7.0.1 >enhancement labels Apr 12, 2019

Yogesh Gaikwad added 5 commits April 12, 2019 21:16

remove unused code

b2b4963

Merge branch 'master' into fix/39878

841f394

remove empty keytab

eaa5965

create file, check if non-file empty krb5.keytab exists as healthcheck

e6eda93

correct the method name

d9e5293

bizybot changed the title ~~WIP: Add support for LDAP bind using SASL GSSAPI~~ Add support for LDAP bind using SASL GSSAPI Apr 15, 2019

bizybot requested review from albertzaharovits and jkakavas April 15, 2019 07:11

bizybot marked this pull request as ready for review April 15, 2019 07:11

colings86 added v6.7.3 and removed v6.7.2 labels Apr 17, 2019

albertzaharovits reviewed Apr 17, 2019

View reviewed changes

albertzaharovits removed v6.7.3 v7.0.1 labels Apr 17, 2019

bizybot changed the title ~~Add support for LDAP bind using SASL GSSAPI~~ Add the capability for the LDAP and AD realms to bind using Kerberos credentials Apr 18, 2019

Yogesh Gaikwad added 6 commits April 18, 2019 12:21

Address review comments

23bfb73

removed use keytab setting

0ee24b1

Increase interval time for kdc kadmin health check

1119857

Merge branch 'master' into fix/39878

986ff5e

add autoheal for openldap container

7a5dc4c

add docs, also make kerberos principal name filtered

b6dba5d

albertzaharovits reviewed Apr 24, 2019

View reviewed changes

Yogesh Gaikwad added 2 commits April 30, 2019 15:53

use filtered for setting instead of dynamic

6fbf757

Merge branch 'master' into fix/39878

460b8aa

bizybot added v7.2.0 and removed v7.2.0 labels May 1, 2019

jasontedor added v7.2.0 and removed v7.2.0 labels May 1, 2019

bizybot removed the v7.2.0 label May 2, 2019

tvernum closed this Oct 31, 2019

jakelandis added v8.0.0-alpha1 and removed v8.0.0 labels Jul 26, 2021

Add the capability for the LDAP and AD realms to bind using Kerberos credentials #41126

Add the capability for the LDAP and AD realms to bind using Kerberos credentials #41126

Uh oh!

Conversation

bizybot commented Apr 11, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bizybot commented Apr 11, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticmachine commented Apr 12, 2019

Uh oh!

bizybot commented Apr 15, 2019

Uh oh!

bizybot commented Apr 15, 2019

Uh oh!

albertzaharovits left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

albertzaharovits Apr 17, 2019

Choose a reason for hiding this comment

Uh oh!

bizybot Apr 17, 2019

Choose a reason for hiding this comment

Uh oh!

albertzaharovits Apr 24, 2019

Choose a reason for hiding this comment

Uh oh!

albertzaharovits Apr 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

albertzaharovits Apr 17, 2019

Choose a reason for hiding this comment

Uh oh!

bizybot Apr 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albertzaharovits Apr 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bizybot Apr 30, 2019

Choose a reason for hiding this comment

Uh oh!

albertzaharovits commented Apr 17, 2019

Uh oh!

albertzaharovits commented Apr 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

albertzaharovits Apr 24, 2019

Choose a reason for hiding this comment

Uh oh!

albertzaharovits Apr 24, 2019

Choose a reason for hiding this comment

Uh oh!

albertzaharovits left a comment

Choose a reason for hiding this comment

Uh oh!

albertzaharovits commented Apr 24, 2019

Uh oh!

bizybot commented May 1, 2019

Uh oh!

tvernum commented Oct 31, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

bizybot commented Apr 11, 2019 •

edited

Loading

bizybot commented Apr 11, 2019 •

edited

Loading

albertzaharovits Apr 24, 2019 •

edited

Loading

bizybot Apr 18, 2019 •

edited

Loading

albertzaharovits Apr 24, 2019 •

edited

Loading

albertzaharovits commented Apr 17, 2019 •

edited

Loading