Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Active Directory: Support load-balanced LDAP servers

Ouverte
  • Quelque chose ne va pas ?
#718 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon
Stack technique
kubernetes
Domaine
authentication

Piste de recherche

Aucun fichier, test ou point d’entrée n’est indiqué. Commencez par suivre la génération de krb5.conf et le comportement de connexion LDAP/Kerberos de user-info-fetcher, puis reproduisez l’équilibrage de charge DNS avec la configuration Stackable 25.3 concernée. C’est terminé lorsque l’authentification LDAP équilibrée en charge fonctionne sans réintroduire les défaillances liées à PTR de Kubernetes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

type/bug
Affected Stackable version

25.3

Affected OpenPolicyAgent version

irrelevant, user-info-fetcher

Current and expected behavior

Currently, we don't support connecting to LDAP servers that are behind DNS-based load balancing, instead just returning a kind-of-useless "not found in Kerberos database" error.

This is because we disable krb5's DNS canonicalization. Normally, it does a "canonicalization dance" for each request. Let's say we try to connect to ldap-lb. That would then be resolved to 1.2.3.4, which is what we do a TCP connection to. Then it would do a reverse DNS (PTR) query for the IP address (1.2.3.4), which returns the hostname for that specific replica (ldap-1). Then it'd use that hostname to build the Kerberos principal that we validate against (ldap/[email protected]).

We disable DNS canonicalization, because it causes other problems in K8s (K8s pods have inconsistent PTR results, which would cause other similar issues depending on the order returned...). That makes krb5 use the specified hostname for the principal instead (ldap/[email protected]). The LDAP server doesn't have that principal, so we fail to authenticate. (The actual "Kerberos database" error is because the Kerberos KDC doesn't have any registered principal with that name.)

Possible solution

I honestly don't know.

We can't just blanket-enable canonicalization, because of the aforementioned K8s issues. But we also need to handle this in some way. Maybe we'll need some flag on which krb5.conf to generate, but that feels like a slippery road to start walking.

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

Langage dominant
Rust
Étoiles
21
Forks
5
Merge moyen
18 h 48 min
PR mergées (30 j)
11

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de stackabletech/opa-operator

Toutes les issues de stackabletech/opa-operator

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.