Discussion :

[Ricou76]

Bonsoir à tous.

Je suis actuellement sur le développement d'une interface Web qui devrait permettre de créer dans l'Active Directory d'un contrôleur de domaine tournant sous Windows Server 2003 des utilisateurs wifi, devant s'authentifier auprès d'un serveur RADIUS.

A la création de compte, l'utilisateur renseigne uniquement le nombre composé de X chiffres qui servira de login, la validité du compte via un contrôle calendar, ainsi qu'une petite description facultative.

Le code ensuite teste la validité du champs "login", la présence et la posteriorité de la date, puis genère un mdp, ajoute le tout dans l'AD et affiche un recapitulatif du compte ainsi créé dont il lance aussitôt l'impression.

J'ai donc utilisé Visual Web Developer au lieu de Web Matrix pour pouvoir ajouter "System.DirectoryServices.dll" comme référence à ce projet.

Lors de l'ajout dans l'AD, j'utilise les paramètres suivant : "UserPrincipalName", "SAMAccountName", "description", "SetPassword", "UserAccountControl", "AccountExpirationDate", mais il me manque un paramètre à configurer pour ces comptes utilisateurs WiFi.

En effet, il me faudrait activer via mon script le contrôle "Autoriser l'accès" dans la partie "Autorisation d'accès distant (appel entrant ou VPN)" de l'onglet "Appel Entrant", accessible par les propriétés de l'utilisateur.

Pour être plus clair, voici un screen :



J'ai beau chercher sur MSDNAA, je ne trouve pas... Merci d'avance de vos tuyaux !

[bossun]

voilà ton bonheur

http://msdn2.microsoft.com/fr-fr/9t2667d1(vs.80).aspx

http://msdn2.microsoft.com/fr-fr/wwzcae1f(vs.80).aspx

http://msdn2.microsoft.com/fr-fr/4b2t08s1(vs.80).aspx

[Ricou76]

Bonjour,

en faisant de nouvelles recherches, je crois avoir trouvé la fameuse proprieté : "msNPAllowDialin".

Par contre, il semblerait que mon AD se doit d'être en mode natif 2003 pour que la proprieté puisse être parametrable.

[Ricou76]

Bonjour, je confirme l'info.

Le domaine passé en mode natif 2003, il est possible via le paramètre "msNPAllowDialin" d'autoriser l'accès distant à l'utilisateur ajouté.

[Ricou76]

Bonjour.

Je reviens vers vous car je suis ennuyé maintenant avec le portage vers le serveur IIS...

Pour info, je tiens à signaler que vous devez installer le FrameWork.net 2.0 pour au moins esperer afficher votre page sur votre IIS...

J'ai eu aussi la désagréable surprise de découvrir que les MsgBox n'étaient pas interpretables par le serveur, ce qui est finalement compréhensible, vu que ces dernières se lanceraient côté serveur... Du coup, obligé de passer tout ca en JS...

Ensuite, plus gros souci : la fonction Invoke de mon utilisateur se fait jeter. voici mon code pour info... Apparement, ce serait une histoire de droit, alors que mon utilisateur se créé nickel via la fonction Properties.


Dim user As DirectoryServices.DirectoryEntry = Ldap.Children.Add(compte, "user")

'' Création du user porteur de badge et initialisation de ses propriétés

'' Nom d'ouverture de session utilisateur
Dim nom_LDAP As String
nom_LDAP = NumBadge.Text + "@blabla.lan"
user.Properties("UserPrincipalName").Add(nom_LDAP)

'' Nom d'ouverture de session utilisateur (antérieur W2K)
user.Properties("SAMAccountName").Add(NumBadge.Text)

'' Champs Description
user.Properties("description").Add(Description.Text)

'' On envoie les modifications au serveur
user.CommitChanges()

'' On va maintenant lui définir son mot de passe.
'' L'utilisateur doit avoir été créé
'' et sauvé avant de pouvoir faire cette étape
user.Invoke("SetPassword", New Object() {password})

Et donc, c'est au moment du Invoke que j'ai une jolie histoire de droit...


Quelqu'un aurait-il une idée ? Merci.

[Ricou76]

Bon, je vais croire à un monologue d'içi peu ^^


J'ai trouvé une astuce, et mon Interface ne plante pas :

user.Invoke("ChangePassword", New Object() {defaut, password})

J'utilise tout simplement le paramètre ChangePassword, pour lequel je définis un variable defaut qui est l'ancien MDP, et bien sûr password qui est mon nouveau.

Par contre, je vais me mettre à la recherche d'une fonction permettant à mon script de récuperer le mot de passe d'un ancien compte, dans le cas où je modifie le compte utilisateur.

[Ricou76]

Bon, pour le changement de mot de passe, j'ai tout simplement preferé vu le contexte d'utilisation de mes comptes la suppression de l'objet via DeleteTree().

[Ricou76]

Maintenant, mon souci est sur les confirmations...

En effet, vu que les MsgBox() sont sources d'erreur quand le script est placé sur le IIS (en même temps, ce n'était pas un affichage client), j'ai dû faire appel à du code Javascript :


Code :

Dim valid As String

valid = "<body><script language = javaScript>if (confirm('L\'utilisateur "
valid += NumBadge.Text
valid += " existe déjà ! \nVoulez-vous continuer ?')) {document.Form1.hide.value='oui';}</scr"
valid += "ipt></body>"

Response.Write(valid)

Le souci est que j'ai l'impression que mon serveur fait tout le code VB.net avant de me lancer ma confirmation dont j'ai besoin pour autoriser ou pas la modification du compte ciblé !!!
Même en enlevant les sources d'erreurs possibles, notament la concaténuation, j'ai le fenêtre de confirmation après le résultat de mon script VB.net...


J'ai de même une erreur JS quand je valide mon Confirm, qui donnerait donc la valeur "oui" à "document.Form1.hide.value" => "document.Form1.hide.value" a la valeur Null ou n'est pas un objet.

Alors j'aimerai savoir au final si ce serait un souci niveau code JS qui me poserait des ennuis, et donc à travailler, ou si le code JS ne serait pas en réalité en interaction avec le code Behind, si bien qu'il faudrait mieux couper court tout de suite à l'implémentation de script JS dans mon code Behind...

Et la solution Ajax ? ce serait le même souci ?

[Zuff69]

En Développement Web, c'est soit le javascript sur le client soit l'asp.net côté serveur donc c'est normale qu'il exécute tout ton code asp.net côté serveur avant d'envoyer ta page côté client pour executer le javascript à son rafraichissement.

La solution la plus simple c'est de forcer le changement de nom (surtout comment veux tu avoir 2 comptes clients identiques dans le LDAP).

Ajax, c'est le même problème car ça ne sert qu'à éviter de rafraichir tout la page mais la logique Javascript/Asp.net reste la même.

Si tu tiens vraiment à ton confirm, il faut que tu développes une fonction javascript qui se déclenche sur le load du body (avec une condition sur une value d'un hidden) qui pose ton confirm et si c'est oui tu déclenches un doPostBack pour relancer ton code asp.net.