ActiveDirectory

1. L'aspect technique

2. L'aspect stratégique

3. L'aspect financier

4. L'aspect juridique

Obliger a acheter un OS + Un annuaire pour mettre en place une évolution de messagerie c'est de la vente liée !!

5. Annexes/Documents techniques

http://manu.all-3rd.net/docs/hsc/docs/publications/ad/html/

Notes:

• NDS : Netware Directory Service (Annuaire de Novell-Netware qui a évolué en eDirectory, annuaire LDAP)
• SAMBA : http://www.samba.org/
• OpenLDAP : http://www.openldap.org/
• SMBOL : Samba / OpenLDAP: Solution qui remplace AD et le serveur de fichier avec ACL
• SambaEdu3 : solution technique(+ACL+Quota+...) en production avec interface d'administration: http://wawadeb.crdp.ac-caen.fr/se3/ doc: http://wawadeb.crdp.ac-caen.fr/se3doc/
• SAM : Security Accounts Manager http://www.laboratoire-microsoft.org/articles/win/secure_sam/
• SAM permission Vulnerability, Windows NT : http://www.ciac.org/ciac/bulletins/h-45.shtml
• ACL : Access Control Liste, http://www.ac-creteil.fr/reseaux/systemes/linux/les-acls.html
• VFS : stackable Virtual File System: http://www.samba.org/samba/docs/man/VFS.html
• SambaTools : Installation et configuration avancé(TLS)de Samba et OpenLDAP: http://samba.idealx.org/smbldap-tools.fr.htm
• Documents Samba en Français (installation, migration, formation) : http://contribs.martymac.org
• Mot de passe sous Windows, la grande inconnue? http://www.cgsecurity.org/Articles/nt_password.html
• NTLM : Windows 2000 Advanced Server Domain Controller Authentication Vulnerability: http://www.net-security.org/vuln.php?id=1883
• NTLM2:

Infos légales: Les noms de produits, services et sociétés mentionnés sont les marques de leurs propriétaires respectifs.

Infos à complier/rajouter

Questions diverses non traitées :

• Est ce que les postes win95, 98 , NT sont utilisables au sein de cette architecture et quelles sont les limitations ?

• Est ce que les postes clients et serveurs d'autres OS sont pris en compte (authentification, mises à jour, etc) ? La politique de sécurité (mots de passes etc ? s'aplique t'elle aussi à d'autres OS ?

• Comment s'intègre un annuaire !Openldap avec une architecture Active Directory ?

• Le Chiffrement de la messagerie (Exchange 2003) -> Quelle est l'impact sur Active Directory ?

• Peut on mixer les architectures Active Directoy et Samba/linux, si oui, quelles sont les limites ?

• Quelle sont les risques si la console principale ou le compte administrateur est piraté, mal utilisée , le serveur principal defectueux : quelle est la conséquense sur le reste de l'architecture ? Quels sont les ports à ouvrir sur la Wan ? La bande passante utilisée pour la réplication ?

• Peut on faire tourner Exchange 5.5 sur un serveur Windows 2000 Membre d'un domaine ?

• Certe Microsoft Exchange 5.5 sp4 fonctionne sur un controleur de domaine principal Samba/Linux mais l'installateur d'exchange 5.5 refuse de fonctionner en présence de Samba/Linux : ce Bug est il corrigé ?

• Quels sont les (grands) comptes qui ont migré vers AC, Samba/Linux pour une architecture (inter)nationale ?

• La modification de la politique de mot de passe sur le dernier patch de sécurité Microsoft était elle nécessaire ou était ce simplement histoire de compliquer la vie des développeurs de Samba/Linux et d'effrayer ceux qui hésitent à installer cette solution ?

  Pas pour les raisons que tu subodores. Supposons que les clients eux ne migrent pas (ou tout du moins, les clients Windows NT passent en 2000/XP).

En fait, en terme de sécurité, Samba+OpenLDAP serait même en dessous (question de supports des hash NTLM2). De plus, avec ADS, tu peux imposer des politiques de sécurité pas trop mal foutues (plus avancées que celles de NT4) sur tous les postes du parc géré par ADS. Plus difficile à faire avec Samba (il y a des techniques, qui fonctionnent à moitié, mais c'est crade...).

La différence se situe ailleurs :

• le coût au déploiement est identique :
  • ADS nécessite une intervention du conseil Microsoft pour l'étude de migration (pas toujours simple)
  • Samba+OpenLDAP aussi
  • le déploiement prend sensiblement le même temps dans un cas comme dans l'autre, donc même coût si ressources externes
• le coût du logiciel n'a plus rien à voir :
  • Samba + OpenLDAP sont libres, et gratuits
  • ADS nécessite l'acquittement d'une redevance annuelle d'environ 30€ (sur le site où je suis intervenu, c'est ce qui avait été estimé) par poste de travail dans le domaine
  • ADS coûte cher côté serveur (j'ai pas de liste de prix)

En fait, pour le prix du conseil au déploiement, on a la même chose que juste le conseil d'architecture chez Microsoft.

Une mauvaise utilisation d'Active Directory n'est elle pas la cause de la panne majeure du département britannique du travail et des retraites ( Department for Work and Pensions (DWP)) : http://news.zdnet.co.uk/software/0,39020381,39175160,00.htm http://www.weblmi.com/sections/articles/2004/11/panne_informatique_h/

>La PKI de Verisign intégrée à AD est-elle un problème et pourquoi?

une PKI gère de la confiance dématérialisée or le capital confiance de MS auprès de certains client et prospects s'érode à cause des révélations (entre autres opensourciennes, par ex depuis publication des Halloween documents (http://www.opensource.org/halloween/) ...) mais également de leur politique de gestion des tarifs et des évolutions (dictée par des impératifs financiers, lire par ex http://www.aaxnet.com/editor/edit029.html#mspath) Microsoft et Verisign ont déjà des casseroles : http://www.transfert.net/a4823

Verisign tout seul n'est pas mal non plus pour quequ'un "de confiance ": http://www.whois.sc/verisign-dns/ http://www.zdnet.fr/actualites/internet/0,39020774,39125027,00.htm http://www.asp-magazine.com/zactus/z/p6750.html http://solutions.journaldunet.com/0310/031016_sondage.shtml

pis : Verisign et MS : code source non publié ou, au mieux et pour certains segments seulement, "insuffisamment publié" car la revue des pairs s'exerce mal lorsque nul tiers ne peut espérer participer activement au projet

qui souhaite gérer de la confiance au moyen d'outils n'en inspirant guère ?

>> Comment peut-on faire pour récuperer les mots de passes sous AD? Cela semble impossible :http://www.annuairesldap.com/article.php?sid=8

>> Peut-on faire évoluer le schéma de AD >> conséquences?

• s'agit-il d'une évolution spécifique (par ex au site) ? pour ce que j'en sais elle rendra difficile/impossible de fusionner simplement des domaines distincts en préservant partout l'extension
• s'agit-il d'une évol du substrat (par ex d'un ajout d'attribut partout disponible) ? pour ce que j'en sais c'est impossible car seul MS décide de ce que tous emploient (contenus des schémas de base). en résumé MS n'est pas l'IANA

>> Qu'est-ce qui m'empêche de passer à AD à part les standards et les coûts?

Rien si tu souhaites tout animer à terme sous un système vendu par MS

Sinon : AD n'offre pas tous les services aux mondes non MS et centralise certaines ressources sur au moins une machine animée par MS-Windows, donc il te faudra en préserver une dans les parages

Cet effet de diffusion aujourd'hui patent pour l'authentification sourd depuis longtemps et gagne rapidement les autres services infostructurels => pour tes postes clients sous MS-Windows il te faudra également confier divers services d'infostructure à des programmes MS

Selon MS tous les programmes, édités par eux ou non, sont bien entendu interopérables mais sur le terrain les experts recommandent d'épauler les clients MS grâce à des serveurs de même type afin de ne pas réduire les fonctions disponibles. Par exemple : noms (chercher dns aging scavenging, dns gss extensions tsig ...) et DDNS, DHCP, annuaire, gestion des tickets d'authentification ...

Ces éléments techniques bloquants ne le demeurent pas tous longtemps mais sont sans cesse renouvelés.

Bref, si tu n'emploies pas les services spécifiques à MS AD (et uniquement fournis aux logiciels MS ...) l'intérêt de maintenir un service AD semble maigre (par ex en matière d'auth : Kerberos ou un SSO bâti sur une PKI constitueraient une solution plus transparente+interopérable+souple+rassie+... et (à service équivalent) moins onéreuse)

L'examen de ces effets sur la couche applicative semble plus révélateur. l'utilisateur d'une fonction spécifique à MS exigera d'en disposer également sur tous les autres postes clients (non MS) afin d'échanger librement des docs. dans le meilleur des cas tu pourras les implémenter ms en ce cas tu ne feras jamais que suivre MS (par ex : tout document produit sur une machine animée par de l'opensource sera parfaitement traitable (sans déperdition) sur un poste MS ... mais la réciproque ne sera pas toujours vraie)

Là encore tout relève de la confiance dont tu les honores. si tu juges qu'ils ne profiteront jamais abusivement de ces verrous afin de satisfaire leurs attentes économiques (financières) voire politiques (donc militaires ?) cela ne pose aucun problème.

A travers MUTUALINFO, EDF R travaille sur cette problématique.