Project

General

Profile

Actions

Support #4540

closed

Authentification LDAP

Added by Damien JAUSSAUD over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Authentification
Target version:
-
Start date:
05/14/2013
Due date:
% Done:

0%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
5.11.2
Système d'exploitation:
Windows 7
Livraison en TEST:
Livraison en PROD:

Description

Bonjour,

Nous avons actuellement 2 contrôlleurs de domaine pour authentifier les utilisateurs (et les administrateurs) en LDAP. Nous avons aussi désigné le domaine au lieu d'un des 2 hôtes dans le fichier autDomainSP.properties afin de permettre la tolérance de panne et les interventions de maintenance sur les contrôlleurs sans interruption de service. Lorsque la plateforme a adopté l'un des 2 et que celui-ci tombe, elle ne bascule pas automatiquement sur l'autre et renvoie une erreur technique à la page de login. Est-il possible de remédier à cela ?

Merci pour votre aide.

Actions #1

Updated by Damien JAUSSAUD over 9 years ago

Bonjour,

Avez-vous une solution svp ? c'est pour nous un cas de single point of failure dans la mesure où, si le contrôleur élu tombe en panne les utilisateurs de la plateforme ne peuvent plus se connecter.

Merci à vous.

Actions #2

Updated by Emmanuel Hugonnet over 9 years ago

La redirection simple au niveau réseau ne suffit elle pas ? Il me semble plutôt logique que ça soit au niveau de l'annuaire ou du routage que cela soit géré plutôt qu'au niveau applicatif.

Actions #3

Updated by Damien JAUSSAUD over 9 years ago

C'est en effet une autre logique , cependant une action de HA via des mécanismes réseau ne relève pas des mêmes compétences. Il faut être capable et prendre temps de le mettre en place, solution moins simple que de modifier une valeur d'un fichier de configuration.

Dans un premier temps, avant de mettre en place une solution alternative, ce qui m'intéresse est de savoir si Silverpeas supporte le scénario suivant:
- Sur le domaine "domaine.local" il y a 2 contrôleurs "dc1.domaine.local" et "dc2.domaine.local" synchronisés et répertoriant tous les utilisateurs de la plateforme Silverpeas "intranet.domaine.local"
- Dans le fichier "autDomainXX.properties" sur la ligne "autServer0.LDAPHost=" la valeur est "domaine.local" au lieu de "dc1.domaine.local" ou "dc2.domaine.local"
- Enfin si le serveur désigné tombe le contrôleur suivant découvert sur le domaine est requêté à sa place.

Je constate pour ma part que Silverpeas élie d'office l'un des 2 avec la valeur "domaine.local" (le premier qui répond ?) et je n'ai pas vu de moyen d'en changer en dehors du fait d'aller désigner le second explicitement dans le fichier. Seulement ce n'est pas de la HA.

Qu'en est-il des capacités de la partie applicative Silverpeas ? Est-ce que ce comportement est connu et normal ? Toujours au niveau de Silverpeas peut-on gérer cela ?

Merci.

Actions #4

Updated by Emmanuel Hugonnet over 9 years ago

C'est jouable au niveau de Silverpeas mais cela demande un développement certain.
En effet que se passe t il lorsque le maître revient en ligne ? Comment détecter on une absence de réponse, quel timeout (sachant que derrière on a une connexion web qui peut elle aussi timeouter) ? Combien de serveur font partie de la grappe ? Comment sélectionne t on le serveur maître ?
La gestion des contrôleurs de domaine et leur découverte est un protocole Microsoft et est propre à l'OS, donc difficilement réalisable et surtout maintenable dans le temsp et les évolutions (non maitrisées) qu'y apportera Microsoft.

Actions #5

Updated by Damien JAUSSAUD over 9 years ago

Pour continuer la réflexion:

Les contrôleurs sont aussi DNS avec des zones intégrées AD. Du coup, lorsqu'une machine lance un ping sur "domaine.local", le premier DNS qui répond renvoie vers lui-même et reste en cache ensuite. Lorsque le cache est vidé, il se peut que le même réponde ou un autre sinon de façon totalement aléatoire. Si on suppose que le DC habituel est tombé, les requêtes DNS n'iront-elles pas naturellement vers le(s) survivants(s) sans se préoccuper du nombre ou du maître ? En fait je pense que l'existance d'un maître n'est pas important.

Si je vous ai posé la question, c'est que j'ai déjà vu ce mécanisme natif sur des solutions de firewall ou NAS sous linux. Sur le Firewall par exemple on peut déclarer autant de DC que l'on souhaite, qui seront requêtés dans un ordre séquentiel "préférentiel". C'est très courant en fait...

Le système déclaratif est bien aussi ce qui évite certains problèmes, une nouvelle question serait donc: peut-on déclarer tout simplement plusieurs serveurs LDAP dans le fichier ? S'il n'y en a que 2, Silverpeas ne tentera que ces 2 et si on en déclare 10, il tentera une fois les 10 de sa liste, l'un après l'autre en s'arrêtant au premier répondant. Si aucun ne répond dans le délai fixé, alors c'est time-out technique.

Les dispositifs d'authentification LDAP sont fréquement utilisés par les éditeurs de toute nature, et je dirais que le vôtre fonctionne bien. Je suppose qu'il faut prendre du recul et utiliser les mécanismes Microsoft pour requêter du Microsoft (clairement on est toujours tributaire de quelque chose) sans tout redévelopper, pour être pérenne et maintenable.

Est-ce que cette proposition vous semble crédible ? J'avoue que je n'ai pas encore essayé de déclarer plusieurs serveurs...

Actions #6

Updated by Damien JAUSSAUD over 9 years ago

Bonne nouvelle, j'ai testé la déclaration de 2 DC et effectivement cela fonctionne: Silverpeas tente de joindre le premier DC (alors hors ligne), et suite à un délai d'expiration de quelques secondes (une vingtaine à peu près) la connexion se fait sur le second.

Je concluerai donc sur cette dernière question: peut-on intervenir quleque part sur le paramètre de time-out afin de le réduire ? Ce serait pour réduire le délai de connexion (confort utilisateur) et potentiellement éviter de récupérer un time-out navigateur après plusieurs sauts.

Actions #7

Updated by Emmanuel Hugonnet over 9 years ago

Cela serait possible mais demande un peu de développement car la propriété de timeout n'est pas gérée par Silverpeas.

Actions #8

Updated by Damien JAUSSAUD over 9 years ago

  • Status changed from New to Closed

Merci.

Actions

Also available in: Atom PDF