Distribution EOLE » Outils Eole » SSO » EoleSSO

Bonjour,

Merci pour votre réponse, j'ai modifié les paramètre comme indiqué mais sans changements sur le comportement :

{"eolesso_ldap_reader_passfile": {"owner": "gen_config", "val": ["/root/.reader1", "/root/.reader2"]}, "eolesso_base_ldap": {"owner": "gen_config", "val": ["o=gouv,c=fr", "ou=personnes,o=ac-grenoble,dc=education,dc=fr"]}, "activer_sso": {"owner": "gen_config", "val": "local"}, "proxy_client_adresse": {"owner": "gen_config", "val": "proxyecole.ac-grenoble.fr"}, "nom_machine": {"owner": "gen_config", "val": "drupal-cas"}, "eolesso_ldap": {"owner": "gen_config", "val": ["ldap-adm.ac-grenoble.fr", "ldap-adm.ac-grenoble.fr"]}, "___version___": "2.5.1", "exim_relay_smtp": {"owner": "gen_config", "val": "smtp.ac-grenoble.fr"}, "nom_domaine_local": {"owner": "gen_config", "val": "ac-grenoble.fr"}, "activer_proxy_client": {"owner": "gen_config", "val": "oui"}, "eolesso_ldap_reader": {"owner": "gen_config", "val": ["uid=assistance,o=ac-grenoble,dc=education,dc=fr", "uid=assistance,o=ac-grenoble,dc=education,dc=fr"]}, "federation_transparente": {"owner": "gen_config", "val": "oui"}, "system_mail_to": {"owner": "gen_config", "val": null}, "eolesso_ldap_apps_params": {"owner": "gen_config", "val": "non"}, "ip_admin_eth0": {"owner": "gen_config", "val": ["172.30.114.0"]}, "numero_etab": {"owner": "gen_config", "val": "0380105H"}, "netmask_admin_eth0": {"owner": "gen_config", "val": ["255.255.255.0"]}, "eolesso_port_ldap": {"owner": "gen_config", "val": [389, 421]}, "ip_ssh_eth0": {"owner": "gen_config", "val": ["172.30.114.0"]}, "libelle_etab": {"owner": "gen_config", "val": "Rectorat de l'acad\u00e9mie de Grenoble"}, "eolesso_ldap_fill_displayname": {"owner": "gen_config", "val": ["displayName", "displayName"]}, "netmask_ssh_eth0": {"owner": "gen_config", "val": ["255.255.255.0"]}, "adresse_ip_eth0": {"owner": "gen_config", "val": "195.221.235.203"}, "domaine_messagerie_etab": {"owner": "gen_config", "val": "smtp.ac-grenoble.fr"}, "nom_academie": {"owner": "gen_config", "val": "ac-grenoble"}, "adresse_ip_gw": {"owner": "gen_config", "val": "195.221.235.199"}, "adresse_netmask_eth0": {"owner": "gen_config", "val": "255.255.255.192"}, "adresse_ip_dns": {"owner": "gen_config", "val": ["193.54.149.20", "193.54.149.11"]}}

J'arrive toujours bien à me connecter sur l'annuaire acad mais sans succès sur le TS : (lvieux sur l'acad, virginie.godart sur le TS) :

Je rajoute la ligne de debug côté LDAPTS :

[20/Jan/2016:11:13:09 +0100] conn=2799201 op=1 msgId=7 - SRCH base="ou=personnes,o=ac-grenoble,dc=education,dc=fr" scope=2 filter="(|(uid=virginie.godart))" attrs="d n"

Pour comparaison, la ligne de debug LDAP sur l'annuaire ACAD :

[root@petunia sun]# tail -f access | grep lvieux
[20/Jan/2016:11:29:51 +0100] conn=19949901 op=1 msgId=36 - SRCH base="o=gouv,c=fr" scope=2 filter="(|(uid=lvieux))" attrs="d n"
[20/Jan/2016:11:29:51 +0100] conn=19949902 op=0 msgId=38 - BIND dn="uid=lvieux,ou=personnels EN,ou=ac-grenoble,ou=education,o=gouv,c=fr" method=128 version=3
[20/Jan/2016:11:29:51 +0100] conn=19949902 op=0 msgId=38 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=lvieux,ou=personnels en,ou=ac-grenoble,ou=education,o=gouv,c=fr"
[20/Jan/2016:11:29:51 +0100] conn=19949902 op=1 msgId=39 - SRCH base="uid=lvieux,ou=personnels en,ou=ac-grenoble,ou=education,o=gouv,c=fr" scope=2 filter="(|(uid=lvieux))" attrs=ALL
[20/Jan/2016:11:29:51 +0100] conn=19949904 op=1 msgId=44 - SRCH base="o=gouv,c=fr" scope=2 filter="(&(objectClass=sambaGroupMapping)(objectClass=posixGroup)(memberUid=lvieux))" attrs=ALL

Pouvez vous vérifier que les commandes suivantes retournent bien les données de l'utilisateur ?

• Si l'authentification se fait par l'intermédiaire d'une fédération ou avec une clé OTP, c'est l'utilisateur 'assistance' qui sera utilisé. Dans ce cas, tester avec :

ldapsearch -x -b "ou=personnes,o=ac-grenoble,dc=education,dc=fr" -h ldap-adm.ac-grenoble.fr -p 421 -D "uid=assistance,o=ac-grenoble,dc=education,dc=fr" -w $(cat /root/.reader2) uid=virginie.godart

Si la fiche de l'utilisateur n'est pas retournée c'est que l'utilisateur "uid=assistance,o=ac-grenoble,dc=education,dc=fr" n'a pas les accès pour la récupérer, ou qu'il y a un problème de configuration (mauvais mot de passe dans le fichier .reader2, utilisateur "assistance" non existant dans l'annuaire TS , ...)

• Si l'authentification est faite directement avec l'utilisateur virginie.godart et un mot de passe classique, c'est un bind sur cet utilisateur qui est effectué.

Dans ce cas, vous pouvez tester avec :

ldapsearch -x -b "ou=personnes,o=ac-grenoble,dc=education,dc=fr" -h ldap-adm.ac-grenoble.fr -p 421 -D "uid=virginie.godart,ou=personnes,o=ac-grenoble,dc=education,dc=fr" -w <mot de passe de virginie.godart> uid=virginie.godart

Si ça ne passe pas, c'est que le mot de passe n'est pas bon (ou qu'il y a un problème d'accès à l'annuaire sur ce port ?)

Merci pour votre réponse,

La première commande fonctionne depuis le serveur CAS :

ldapsearch -x -b "ou=personnes,o=ac-grenoble,dc=education,dc=fr" -h ldap-adm.ac-grenoble.fr -p 421 -D "uid=assistance,o=ac-grenoble,dc=education,dc=fr" -w $(cat /root/.reader2) uid=virginie.godart
# extended LDIF
#
# LDAPv3
# base <ou=personnes,o=ac-grenoble,dc=education,dc=fr> with scope subtree
# filter: uid=virginie.godart
# requesting: ALL
#

$FICHE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

La seconde ne fonctionne pas :

root@drupal-cas:~# ldapsearch -x -b "ou=personnes,o=ac-grenoble,dc=education,dc=fr" -h ldap-adm.ac-grenoble.fr -p 421 -D "uid=virginie.godart,ou=personnes,o=ac-grenoble,dc=education,dc=fr" -w $MDP  uid=virginie.godart# extended LDIF
#
# LDAPv3
# base <ou=personnes,o=ac-grenoble,dc=education,dc=fr> with scope subtree
# filter: uid=virginie.godart
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

Le compte testé ici fait partie de l'annuaire TS que le CAS intérroge pour accéder aux applis. Est-ce que ces résultats vous parlent ?

Cdt,

LV

Je crois comprendre l'idée, l'utilisateur n'a pas le droit de demander son uid et c'est ce que les logs montrent :

[root@alpinia sunTS]# tail -f access | grep virginie.godart
[20/Jan/2016:14:41:01 +0100] conn=2805463 op=0 msgId=1 - BIND dn="uid=virginie.godart,ou=personnes,o=ac-grenoble,dc=education,dc=fr" method=128 version=3
[20/Jan/2016:14:41:01 +0100] conn=2805463 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=virginie.godart,ou=personnes,o=ac-grenoble,dc=education,dc=fr"
[20/Jan/2016:14:41:01 +0100] conn=2805463 op=1 msgId=2 - SRCH base="ou=personnes,o=ac-grenoble,dc=education,dc=fr" scope=2 filter="(uid=virginie.godart)" attrs=ALL

Il va falloir modifier les paramètres de self request. Qu'en pensez-vous ?

J'allais justement vous répondre dans ce sens

Je ne vois pas trop d'autre solution que modifier les acls, à moins que la correspondance avec le login puisse se faire sur un autre attribut qui serait accessible (je ne connais pas l'architecture de l'annuaire TS, tout dépend de la façon dont il est provisionné). Dans ce cas, il est possible de spécifier l'attribut de recherche à utiliser pour chaque annuaire dans gen_config.

La demande ayant servi de fil de discussion, je ne la ferme pas dans l'immédiat.

Pouvez vous nous confirmer que le problème est résolu afin de terminer son traitement ?

Bonjour,

J'attends le retour du pôle d'Orleans pour le debug sur le LDAP et je vous confirme que l'erreur vient de là. Merci de votre aide.

Bonjour,

Suite aux modifications que nous avons éffectuées avec le pôle Identité, l'utilisateur peut maintenant s'auto-interroger en terme de LDAP sur son attribut UID. Lorsque l'on paramètre le 2ème serveur sur le port 421, le problème est résolu et la connexion se fait sans soucis.

Seul hic, lorsque que c'est l'IP de la VIP qui est configué dans le CAS, la connexion ne se fait pas...

Je ne pense pas que ce soit lié au CAS mais je vous en parle à tout hasard ?

Bien cordialement,

LV.

Les logs qui apparaissent lorsque l'on mzet la VIP sur le port 421 :

2016-01-25T11:42:07.857231+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] /etc/resolv.conf changed, reparsing
2016-01-25T11:42:07.857580+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Resolver added ('193.54.149.20', 53) to server list
2016-01-25T11:42:07.857732+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Resolver added ('193.54.149.11', 53) to server list
2016-01-25T11:42:07.858851+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] DNSDatagramProtocol starting on 16010
2016-01-25T11:42:07.859025+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Starting protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910364d0>
2016-01-25T11:42:07.886307+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] (UDP Port 16010 Closed)
2016-01-25T11:42:07.886472+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Stopping protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910364d0>
2016-01-25T11:42:37.897286+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] DNSDatagramProtocol starting on 818
2016-01-25T11:42:37.897330+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Starting protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910388d0>
2016-01-25T11:42:37.898286+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] (UDP Port 818 Closed)
2016-01-25T11:42:37.898454+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Stopping protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910388d0>
2016-01-25T11:43:07.900672+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] ! Echec de l'authentification : virginie.godart !

En fait, ce qui est très étonnant c'est l'adresse 172.30.112.68 qui train dans le log. En effet, avant, les machiens étaient sur ce réseau mais ce n'est plus d'actualité et les paramètres de conf ne montre pas d'artéfacts de conf. C'est l'adresse d'un proxy du réseau 112...

En fait le problème ne vient pas de là non plus. Voilà un descriptif complet et plus clair.

Il y a 2 ldap configuré, un TS et un ACAD, les deux sont sur le même serveur (ldap-adm) mais pas sur le même port (389 et 421).

Dans les paramètres du gen_config on a :

serveur 1 : ldap-adm.ac-grenoble.fr port 389 > connexion acceptée depuis le CAS, fonctionel.
serveur 2 CONFIGURE AVEC LE NOM DNS : ldap-adm.ac-grenoble.fr port 421 > connexion non acceptée depuis le CAS, non fonctionel.

2016-01-25T11:42:07.857231+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] /etc/resolv.conf changed, reparsing
2016-01-25T11:42:07.857580+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Resolver added ('193.54.149.20', 53) to server list
2016-01-25T11:42:07.857732+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Resolver added ('193.54.149.11', 53) to server list
2016-01-25T11:42:07.858851+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] DNSDatagramProtocol starting on 16010
2016-01-25T11:42:07.859025+01:00 drupal-cas.ac-grenoble.fr eolesso: [HTTPChannel (TLSProtocolWrapper),7,172.30.112.68] Starting protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910364d0>
2016-01-25T11:42:07.886307+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] (UDP Port 16010 Closed)
2016-01-25T11:42:07.886472+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Stopping protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910364d0>
2016-01-25T11:42:37.897286+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] DNSDatagramProtocol starting on 818
2016-01-25T11:42:37.897330+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Starting protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910388d0>
2016-01-25T11:42:37.898286+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] (UDP Port 818 Closed)
2016-01-25T11:42:37.898454+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] Stopping protocol <twisted.names.dns.DNSDatagramProtocol object at 0x7fa9910388d0>
2016-01-25T11:43:07.900672+01:00 drupal-cas.ac-grenoble.fr eolesso: [-] ! Echec de l'authentification : virginie.godart !

Si on configure le serveur 2 avec l'adresse IP alors les connexion vers le serveur TS fonctionne...N'y aurait-il pas un bug quelque part ? Il me semble que nos conf DNS sont ok.

Je crois que j'ai trouvé le problème :

Le CAS ne supporte pas d'avoir le même paramètre (port différent) pour les 2 LDAP. Si on met les 2 adresses IP du ldap ça ne marche pas, si on met les 2 noms dns ça ne marche pas, si on mets l'adresse IP pour l'un, le nom DSN pour l'autre ça fonctionne. Pouvez-vous voir ça côté eole ?

Cdt,

LV

ERRATA¶

Le problème est présent depuis la version 2.3.

Il est corrigé à partir de la version 2.5.2.

Pour contourner le problème dans les autres versions, configurer avec des noms d'hôtes différents pour chaque annuaire (nom dns / ip ou plusieurs noms dns pointant sur l'adresse)