Sommaire

  1. Modifications au niveau de auth.auf
  2. Ajustements en région
  3. Reste à vérifier…
  4. La suite du processus

Modifications au niveau de auth.auf

Commandes SQL lancées sur db-srv.auf : 

CREATE VIEW "Authentification".courriels_export4 AS
  SELECT
    u.id, u.courriel, u.domaine, COALESCE(u.mdp_crypt6,'*') AS motdepasse,
    u.pays, u.redirection_courriel, u.coda, u.prenom, u.nom, u.valide,
    t.poste_tel_conv, t.tel_ip
  FROM "Authentification".utilisateurs u
  LEFT JOIN "Authentification".telephonie t
    ON u.id=t.id_utilisateur;

CREATE USER courriel_sec4 PASSWORD 'même-chose-moins-1-à-chaque-chiffre';

GRANT USAGE ON SCHEMA "Authentification" TO courriel_sec4;
GRANT SELECT ON "Authentification".courriels_export4 TO courriel_sec4;

Configuration des accès dans /etc/postgresql/9.1/main/pg_hba.conf : 

# Accès depuis Paris
host    AUF     courriel_sec4   10.72.0.254/32          md5
host    AUF     aufrefer        10.72.0.254/32          md5

# Accès depuis Dakar - serveur bao.sn.auf
host    AUF     courriel_sec4   10.196.1.1/32           md5

# Accès depuis Alger
host    AUF     courriel_sec4   10.59.1.1/32            md5

Ajustements en région

Reste à vérifier…

Accès aux mots de passe via auf-refer : 

AUF=# select * from "Authentification".machines;
 pays |  adresse_ip  | cle | date_creation | date_modification 
------+--------------+-----+---------------+-------------------
  vn  | 10.230.0.9   |     | 2010-03-03    | 2010-03-03
  ca  | 10.36.0.18   | xxx | 2011-10-18    | 2011-10-18
  mg  | 10.134.1.250 | xxx | 2011-10-18    | 2011-10-18
  ro  | 10.181.1.9   | xxx | 2011-10-27    | 2011-10-27

La suite du processus

  1. Phase 2 : Choses à faire avant la comm
    • tests : 48 heures (ou plus) après le changement de mdp sur ID.AUF, faire le tour des systèmes pour voir si ça passe toujours (en particulier ceux pas web ou pas sur ID.AUF ni LDAP) ou bien si c'est resté sur l'ancien mdp, les inventorier le cas échéant
    • passer TGV sur new-intranet et sous ID.AUF via intranet.auf.org
    • s'assurer que les synchros PostgreSQL en régions utilisent bien le bon accès (en coupant l'ancien accès après confirmation)
      • RTR : confirmer le passage au crypt6 chez vous
      • couper les accès aux synchros autres que crypt6
      • mettre à jour crypt en plus de crypt6 lors d'un changement de mdp dans ID.AUF
    • désactiver le changement de mot de passe par les Tech dans auth.auf
    • générer un mot de passe initial aléatoire lors de la création d'un nouveau compte
  2. Phase 3 : Faire un message de communication très clair et simple : impacts du changement de mdp, systèmes touchés, délais, perte de mdp ...
    • le mdp AUF principal se changera dans ID.AUF
    • réduit encore le nombre de mdp
    • changement sera répercuté sous 10 minutes dans le LDAP de Montréal et le nouveau mdp sera donc à utiliser pour Jabber (Pidgin) ou le Nuage AUF (ownCloud) aussi.
    • changement sera répercuté sous 1 heure en région pour SOGo et les systèmes qui utilisent la BdD SOGo
    • utilisé pour le courriel (IMAP et smtp)
    • utilisateur perd son mot de passe ID.AUF : contacter Montréal (Moussa ou JC) pour en mettre un nouveau temporairement
    • annoncer la campagne de changement de mot de passe (juste les utilisateurs n'ayant pas de crypt6 ?)
  3. Phase 4
    • BAP : traiter la synchro auf-refer dans un second temps, car il faut d'abord faire changer leurs mots de passe à ceux qui ne sont pas en crypt6
    • ajuster auf-refer pour utiliser lui aussi crypt6 (actuellement c'est crypt6 si possible, ou crypt1 à défaut)
    • lister les utilisateurs qui ont un champ crypt6 vide et leur faire changer leur mdp dans ID.AUF

    • ajouter un envoi de courriel à <alerte-securite@auf.org> à chaque changement de mdp

    • changer le message qui indique quoi faire en cas de perte de mdp
    • ajuster ID.AUF pour non seulement mettre à jour crypt6 mais aussi invalider md5 et crypt1 au passage (en y mettant une valeur bloquante, genre "!INVALIDE!")
  4. Phase 5 : à terme
    • refaire auth.auf en python