Creer user dans l'AD avec execution en tant que

Version imprimable

30/03/2011, 17h13
thibgrev

Creer user dans l'AD avec execution en tant que

Bonjour a tous,

Je sais que beaucoup de discussions ont eu lieu sur ce sujet mais après avoir bien cherché sur le net, aucune ne m'a apporté la solution, d'ou ce besoin d'aide.

Le but : créer un user dans l'AD.

Simple mais :
le script exécuté par une personne doit se connecter "en tant que" sur l'AD via un compte de service. (La personne n'a pas ce droit de base)

Il y aura deux actions a réaliser,

-lister des informations : login de "ou=Utilisateurs,dc=nom,dc=com" pour déterminer le login suivant
Pour cette tâche, c'est OK car je peux le faire sans exécution en tant que, le simple utilisateur du domaine peut faire cette requête ;)
-créer le compte utilisateur avec ce login :aie:

Donc, si quelqu'un sait comment se connecter à l'AD "en tant que" et créer un compte user, merci d'avance pour cette aide,
30/03/2011, 21h45
thibgrev

Possible en lecture seule

Apport d'information:

La connexion "en tant que" existe en utilisant ADODB, voir sur:
Script avec authentification intégré
La connection a l'AD est paramétrée comme suit:
Conn.Open "ADs Provider", "cn=Administrator,ou=users,dc=domaine,dc=fr","pwd"

Cependant, d'après les quelques sources, cette technique permettrait que de la lecture seule via une requete SQL "SELECT...."

Solution testée, ça fonctionne
A suivre...

Pour une future création de compte j'ai à disposition le script suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
' ------------------------------------------------------' 
Option Explicit
Dim objConnection, objCommand, objRecordSet 
Dim strUserAccount, strFullName, strLastName, strFirstName, strMail, strPassword
Dim objRootLDAP, objContainer, objNewUser
Dim var, intAccValue, intPwdValue
 
strPassword = "P@ssw0rd"
 
' Here is where we set the value to enable the account
' 512 = Enable, 514 = Disable.
intAccValue = 512 
intPwdValue = 0 ' Default is -1 : 0 to change
 
set var = WScript.Arguments 
 
strUserAccount = var(0)
strFullName = var(1)
strLastName = var(2)
strFirstName = var(3)
strMail = var(4) 
 
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=ADsDSOObject;"
 
Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
 
objCommand.CommandText = _
    "<LDAP://dc=xxxx,dc=xxx,dc=local>;(&(objectCategory=User)" & _
         "(samAccountName=" & strUserAccount & "));samAccountName;subtree"
 
Set objRecordSet = objCommand.Execute
 
If objRecordset.RecordCount = 0 Then
 
' Bind to Active Directory, Users container.
Set objRootLDAP = GetObject("LDAP://xxxxx")
Set objContainer = GetObject("LDAP://OU=xxxxx," & _
objRootLDAP.Get("defaultNamingContext")) 
 
' Build the actual User.
Set objNewUser = objContainer.Create("User", "cn=" & strFullName)
objNewUser.Put "sAMAccountName", strUserAccount
objNewUser.Put "displayName", strFullName
objNewUser.Put "sn", strLastName
objNewUser.Put "givenName", strFirstName
objNewUser.Put "mail", strMail
objNewUser.SetInfo 
 
objNewUser.SetPassword strPassword
objNewUser.Put "userAccountControl", intAccValue
objNewUser.Put "PwdLastSet", intPwdValue
objNewUser.SetInfo
 
Else
    WScript.Echo strUserAccount & " already exists."
End If
 
objConnection.Close
WScript.Quit 
 
' End of free sample Create Users VBScript.

Par contre je ne l'ai pas encore testé ;)

01/04/2011, 17h18
thibgrev

Création de compte

Merci a toi Ced600 pour ta réponse,

en fait ton script, sauf erreur de ma part, est parfait pour la création d'un compte dans l'AD et la saisie des informations qui lui sont propres mais il ne correspond pas à ce que je recherche car il s'appuie sur les droits de la personne qui éxecute ce script (En gros, kerberos)

Pour la première partie de ton script; tu va "juste" faire une requête vers l'Ad en "lecture seule". Pour le type de connexion utilisée "ADODB.Connection", tu peux renseigner un login/password. Il faudrait que tu modifies:

Code:

objConnection.Open "Provider=ADsDSOObject;" -> objConnection.Open "Provider=ADsDSOObject;", "compte@domaine.fr","password"

Pour la seconde partie de ton script, tu vas créer l'user s'il n'existe pas. Dans ce cas là, la technique utilisée n'est plus l'ADODB. Alors, l'utilisateur devra posséder les droits requis pour effectuer cette requête (Kerberos interrogé).

e que je recherche, c'est un moyen d'accéder à l'AD via script en lecture/écriture grâce à une authentification avec login/password. En gros, cela revient à donner des droits aux utilisateurs du script alors que, e base, ils ne les ont pas.

Je commence à penser que ceci n'est pas réalisable....:calim2:
04/04/2011, 14h31
ced600

Ok pour l'explication du script et merci pour les détails, je ne m'étais pas encore trop penché dessus ne l'ayant pas ecrit.

Mais juste pour une question de logique, pouquoi autoriser une personne via script à créer des user sur l'AD alors qu'il n'en pas le droit ?
J'ai l'impression que tu détournes le processus mis en place dans ta boite pour l'attribution de droit sur l'ad, non ?
Je peux comprendre ce genre de chose, lorsque des lenteurs internes ne te permet de faire que dans 3 semaines ce qui doit être fait dans 3 jours.

Bon bref, en dehors d'un détournement de processus, ne pourrais tu pas demander aux admins AD de donner les droits temporairement (ou définitivement) à ces users qui "peuvent" créer des comptes ?

En plus un tel script serait dangereux s'il tombe entre de mauvaise main.
Peut être pour cela que ce n'est pas possible de le faire. Pour ne pas introduire une faille de sécurité ?
04/04/2011, 15h03
thibgrev

Tout a fait d'accorrd avec toi, c'est donner des droits à des users alors qu'ils ne les ont pas. Je ne suis pas pour ceci, je préférerai une délégation de droits de l'AD sur les users cible mais ce n'est pas ce qu'on m'a demandé de faire... dommage :cry:

Juste pour info : sur le serveur, le script vbs fera tout le boulot, c'est à dire, créera l'utilisateur, le mettra dans le groupe... Ce script sera appelé via un user sur un PC grâce à WinRS (Remote Shell).

La solution:

Pour ces problèmes de droit, la solution sera celle-ci : on utilisera CPAU sur le server. l’exécution via WinRS aura comme point d'entrée sur le serveur CPAU qui permettra d'utiliser un login/password pour faire la connexion "en tant que" sur l'AD. Le login/password sera stocké via un fichier crypté hébergé sur le serveur. (Pas de faille de sécurité) :P, l'accès au script vbs est bien entendu limité aux users déterminés

Donc, en somme, pas de solution trouvée via vbs... merci quand même pour tes réponse! :mrgreen:

Pour tout ceux qui se penche sur cette question, je vous conseille d'utiliser PowerShell, dans un script on peut très facilement utiliser "-credential" pour indiquer un compte afin de faire les opérations! :P

Voir sur http://bsonposh.com/archives/338

Solution trouvée

La solution au problème est trouvée,
On peut réellement s'identifier sur l'AD dans un vbs en utilisant un compte différent tout en accédant à de la lecture/modification.

Voici le code qui crée un user via un compte spécifié:
(Ce script a été testé sur un user "Utilisateur du domaine", sans aucun droit particulier et ca fonctionne)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
strUserDN2 = "adminWinRS@domaine" 
strPassword2 = "azerty@1" 
strPassword = "123456789Az@" 
 
Set objDSO = GetObject("LDAP:") 
 
' CREATION Du compte utilisateur 
Set objOU = objDSO.OpenDSObject("LDAP://OU=Utilisateurs,dc=domaine,dc=fr", strUserDN2, strPassword2, 1) 
 
Set oUser = objOU.Create("User", "cn=nom prenom") 
oUser.Put "sAMAccountName", "nom prenom" 
oUser.Put "givenName","prenom" 
oUser.Put "sn","autre" 
oUser.Put "userPrincipalName","azerty" 
oUser.SetInfo 
 
 
' Changement du mot de passe et activation du compte 
Set oUser = objDSO.OpenDSObject("LDAP://CN=nom prenom,OU=Utilisateurs,dc=domaine,dc=fr", strUserDN2, strPassword2,1) 
 
'Set User Password 
oUser.SetPassword strPassword 
 
'Activate Account 
oUser.Put "userAccountControl", "512" 
 
oUser.SetInfo 
 
' Cloture 
oUser = null 
objOU = null 
objDSO = null

07/04/2011, 11h41
ced600

Par contre si tu laisses en clair le compte et mot de passe dans le script, n'importe qui ayant accés à ce script à accés à un compte admin sur l'ad qui peut à la rigueur faire plus que ajouter des users :aie:
Dans cette situation cela revient presque à fournir les droits admins AD aux utilisateurs qui ont accés à ce script. :aie: :aie:
Peut être prévoir une limitation de droit sur ce compte, non ?
Il y a aussi une version encrypté de VBS, je ne suis plus sur du nom VBE je crois. La version encrypté rend illisible le contenue du script si l'on n'a pas la clé de décryptage si je ne me trompe pas.
07/04/2011, 21h11
thibgrev

Tu as tout a fait raison ced600, le fait que le login/pwd soit en clair est réellement un problème.

Dans mon cas, ça ne l'ai pas forcément car le script, posé sur un serveur ,n'est accessible qu'a partir de WinRS. Nous permettons ainsi QUE l’exécution du script. Sa consultation, sa copie... est interdite car est soumis à ses droits Windows.
La, on parle vraiment d’exécution a distance.

L'utilisateur aura sur son poste un hta, ce sera un formulaire avec nom, prenom..... Quand il cliquera sur "Valider" une requete WinRS partira vers le serveur.
LE listener du serveur autorisera certains user a se connecter. Dans le cas d'une autorisation, l'éxecution du vbs du serveur se fera et va créer l'user dans l'AD avec toutes les informations saisies en amont.
La sécurité est donc gérée par l'execution e WinRS : nous créons un groupe avec les users autorisés. Il suffit, après, d'autoriser le groupe à utiliser le listener.

Concernant le vbe, justement j'ai étudié cette techno, et, je peux me tromper, mais ça me parait être plutôt du code compilé que crypté car j'ai pu aisément transformer un .vbe en .vbs grâce à un soft "fait pour"....

J'ai spécialement détaillé le fonctionnement si ca intéresse du monde, en tout cas, merci pour tes remarques ced600 c'est toujours intéressant d'appréhender ces problèmes de sécurité.
07/04/2011, 21h13
thibgrev

Concernant :

"Dans cette situation cela revient presque à fournir les droits admins AD aux utilisateurs qui ont accés à ce script"

Tu as raison, c'est le but des opérations. Les utilisateurs autorisés auront ces droits et vont créer des users sans se connecter à l'AD.
Evidemment, ce projet est destiné à des personne du service informatique :mrgreen:

@+
08/04/2011, 08h58
ced600

Ok

N'oublie pas le petit tag résolu ;)