Sommaire

  1. Modifications au niveau de auth.auf
  2. Ajustements en région
  3. Reste à vérifier…
  4. La suite du processus
  5. Procédure de test
  6. Sous pages

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. Notes :
    • distinguer 2 types de mot de passe
      • par défaut le mdp de tout le monde peut être considéré comme "faible" (il est enregistré "partout" : ordi, téléphone, etc.)
      • il faudrait donc ajouter un second niveau d'authentification pour les SI sensibles (ex. SIRH), comme c'est déjà le cas pour CODA
    • garder un historique des mdp
      • retenir les 3 derniers
      • au changement de mdp, rejeter les saisies identiques à l'un des 3 derniers
  2. Phase 2
    • 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
      • webmail SOGo (pour les implantations en région) : authentification Imap pas synchronisé avec le central
        • solution : synchro authentification SOGo vers les serveurs Imap locaux

      • auth.auf (TGV et gestion des alias) : ne peut pas utiliser crypt6 (serveur < Squeeze)

        • solution : mettre à jour crypt en plus de crypt6 lors d'un changement de mdp dans ID.AUF, après avoir coupé les synchros non crypt6 vers les régions
    • s'assurer que les synchros PostgreSQL en régions utilisent bien le bon accès (en coupant l'ancien accès après confirmation) (BAO, BM, BAP)
      • 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
    • faire que le changement de mot de passe par les Tech dans auth.auf change aussi ID.AUF
  3. 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 ?)
  4. 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!")

    • passer TGV et la gestion des alias sur un serveur >= Squeeze et sous ID.AUF via intranet.auf.org (nécessite du développement)

    • 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
  5. Phase 5 : à terme
    • refaire auth.auf en python

Procédure de test

  1. changer ton mot de passe dans ID.AUF (lien direct https://id.auf.org/accounts/password/change/ )

  2. se déconnecter de id.auf (depuis https://id.auf.org/ )

  3. vérifier tes accès à TOUS les services
    • ré-ouverture de session sur l'ordinateur si concerné ;
    • test TB (màj mdp dans TB) ;
    • test SOGo (màj mdp dans FF) ;
    • test messagerie sur téléphone intelligent si applicable
    • test messagerie secours
    • test SOGo
    • test nuage (web et client lourd)
    • portail captif wifi-auf
    • + tout autre test pertinent.
  4. lister les éventuelles conséquences (délai de propagation, système bloqué, système utilisant toujours l'ancien mot de passe, ...)

Sous pages

  1. AméliorationSécuritéSeptembre2016/MotDePasse/TestJC

AméliorationSécuritéSeptembre2016/MotDePasse (dernière édition le 2016-11-09 02:03:52 par MoussaNombre)