Squid et les noms d'utilisateur en double dans les annuaires LDAP

Si deux annuaires indépendants contiennent tous les deux alex, le proxy doit choisir un annuaire avant de vérifier un mot de passe. Essayer A puis B dissimule ce choix dans l'échec d'authentification et peut confondre un annuaire indisponible avec un secret rejeté.

Deux dispositions peuvent rendre l'identité explicite :

• Connexion qualifiée. Un nom tel que [email protected] sélectionne, via un répartiteur, un annuaire fixe défini par l'administrateur. Conservez l'identité qualifiée pour l'autorisation et la journalisation. Ne transformez pas un suffixe fourni par le client en adresse arbitraire de serveur LDAP.
• Contexte de requête fiable et stable. Un écouteur ou un autre contexte pris en charge sélectionne l'annuaire. Définissez ce qui se passe lorsqu'une personne se déplace ou utilise un autre écouteur ; l'emplacement réseau n'est pas une identité personnelle.

Les répliques d'un annuaire sont différentes : elles partagent un espace de noms d'identité. Des annuaires sans rapport ne deviennent pas des répliques du fait que tous deux utilisent LDAP.

Faites concorder la clé du cache d'informations d'identification de Squid avec la sélection de l'assistant. La référence auth_param décrit key_extras pour transmettre un contexte supplémentaire et l'inclure dans la clé de cache, y compris le cas de noms identiques distingués par le port d'écoute. L'assistant doit comprendre l'entrée étendue, et la macro choisie doit être disponible à cette étape d'authentification.

Préférez un contexte stable. Une IP client qui change souvent peut multiplier les identités en cache et modifier des contrôles qui attendent une seule identité utilisateur.

Définissez séparément annuaire inconnu, compte inconnu, mot de passe rejeté et annuaire indisponible. Le compte de North ne doit pas devenir silencieusement l'Alex de South lorsque North est indisponible. Gardez ces résultats distinguables dans les journaux sans enregistrer de mots de passe.