ChangePasswordEntry.asp et ChangePassword1.asp contiennent peu de lignes de code, mais fournissent l'interface Web pour permettre aux utilisateurs de changer leurs mots de passe sur le Web ou dans un intranet. Le code fonctionne si le serveur tourne sous Windows 2000 ou Windows NT 4.0 avec des utilisateurs dont les comptes
Travailler avec Active Directory et les domaines Windows NT
sont stockés sur le serveur local. En revanche, il ne fonctionne pas si le serveur
Web exécute Windows 2000 (et donc Active Directory) ou s’il participe à un domaine
Windows NT.
Pour faire fonctionner ChangePassword1.asp pour les comptes d’utilisateurs stockés
dans la base de données Active Directory de Windows 2000, il faut utiliser le
fournisseur LDAP (Lightweight Directory Access Protocol) pour ADSI au lieu du
fournisseur WinNT. Il permet d’effectuer des tâches sur un serveur faisant partie
d’un domaine Active Directory. Pour utiliser le fournisseur LDAP, il suffit de
changer la chaîne de connexion de ChangePassword1.asp en
sConnectString = « LDAP://CN= » &
sUser & « ,OU=users, » &
« DC=mycompany, DC=Com »
Les changements apportés par cette modification de paramètres adaptent la chaîne
de connexion à l’interface d’Active Directory. Au lieu de ne transmettre simplement
que des paramètres positionnels, comme le fait le fournisseur WinNT, le code du
fournisseur LDAP utilise des identifiants Active Directory (tels que CN pour le
nom et OU pour les unités organisationnelles). Une fois que la fonction GetObject
a exécuté la chaîne de connexion, on peut travailler avec le fournisseur LDAP
exactement comme avec le fournisseur WinNT. Excepté les changements de la chaîne
de connexion, le code reste le même, que l’on utilise le fournisseur WinNT ou
le fournisseur LDAP.
Pour que le code ChangePassword1.asp fonctionne dans un domaine NT 4.0, la chaîne
de connexion doit spécifier le nom du domaine au lieu du nom d’ordinateur. Par
exemple :
sConnectString = « WinNT:// » &
« MyDomain/ » & sUser & « ,user »
définit la chaîne de connexion pour qu’elle désigne l’objet utilisateur MyDomain,
au lieu de l’ordinateur exécutant le serveur Web. Comme on peut le voir, l’intérêt
d’ADSI est de permettre d’utiliser pratiquement le même code pour accéder aux
objets des comptes d’utilisateurs de Windows 2000 ou de Windows NT 4.0.
Téléchargez cette ressource
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
Les plus consultés sur iTPro.fr
- Sekoia.io : l’alternative européenne qui s’impose dans la cybersécurité
- Redéfinir la confiance à l’ère de l’IA agentique : les entreprises sont-elles prêtes pour le SOC autonome ?
- IA Agentique : la vraie rupture c’est la gouvernance humaine
- Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
Articles les + lus
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
À la une de la chaîne Tech
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
