This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

AudioJam

Comment Utiliser Un Script Kixtart Pour Attaquer La Base Ldap Du Directory Server ?

Messages recommandés

Bonjour,

Je suis conscient que ma question s'écarte peut-être un peu du domaine couvert par ce forum, mais au regard des compétences de certains de ses membres, il y a peut-être quelqu'un qui peut apporter une réponse à mon problème !

La situation :

Mon but est de pouvoir mettre en place des NAS Synology pour remplacer les serveurs Linux (Samba) ou Windows (ADS) utilisés actuellement au sein de petites structures décentralisés (moins de 10 postes clients). Imaginez une organisation basée sur quelques sièges principaux, dans lesquels une structure client/serveur à part entière existe pour gérer les centaines de clients connectés. Ces sites sont présents dans quelques pays soigneusement sélectionnés et disposent de toutes les technologies actuelles en termes d'infrastructure et de communication. Autour de ces quelques sites principaux, orbite une multitude d'entités, allant du poste seul jusqu'aux petits centres avec quelques dizaines de postes. Tous ces sites "distants" sont actuellement équipés d'un serveur (souvent très basique) avec au moins les services Samba ou ADS pour l'authentification des utilisateurs. La plupart de ces sites se trouvent dans des zones reculées et ne disposent que de très mauvaises connexions Internet (quand il y en a une !). Il s'agit le plus souvent d'une connexion modem 56K et les coupures sont "très" fréquentes (jusqu'à 50 par jour !) et parfois très longues (des jours, voir des semaines !). Par conséquent, je ne vous fait pas un dessin, mais la maintenance du parc est juste impossible. Ajoutez à cela une disponibilité locale en matériel informatique plus que limitée et une alimentation en courant électrique pour le moins "fluctuante" et vous aurez une bonne idée des défis auxquels nous devons faire face !

Depuis quelques temps déjà, nous avons commencé à remplacer certains serveurs par des NAS Synology (des modèles de 2 à 5 baies en fonctions des besoins). Cette solution présente l'avantage d'être moins gourmande en électricité et d'être beaucoup plus simple à maintenir. De plus, la possibilité d'exporter/importer les configurations rapidement ou la facilité avec laquelle on peut remplacer les disques (reconstruction automatique du RAID) sont des caractéristiques cruciales pour garantir un fonctionnement pérenne. Mais le plus gros problème auquel nous sommes confrontés est la gestion des utilisateurs. Il faut en effet que cette gestion soit aussi flexible que possible (les utilisateurs naviguent d'un site à l'autre et doivent avoir un accès personnel sur chacun d'entre eux) tout en garantissant un minimum de sécurité (les données concernées sont souvent très, très sensibles).

Depuis l'apparition de Directory Server, nous avons franchi un cap important dans la résolution de ce problème. En effet, la mise en place de Directory Server sur le NAS et l'utilisation conjointe de pGina (avec le plugin LDAPAuth) sur les postes clients, nous permet de mettre en place une authentification simple et efficace pour ces sites. Par contre, cela nous pose encore quelques problèmes au niveau des scripts de connexion. Notre environnement de test est le suivant :

- Synology DS1511+ avec 3 disques 1To en RAID-5

- DSM 3.2-1922

- Directory Server 1.0-1922

- KiXtart 4.62 et KixForms 2.46

- Imprimante Laser N&B HP LaserJet 2300N (connectée en réseau et non en USB)

- Switch HP ProCurve 1810-8G (8 ports Gigabit)

Les scripts de connexion sont réalisés avec des commandes KiXtart, et le principe même de toute la sécurité des répertoires est basé sur l'appartenance des utilisateurs à des groupes :

- Utilisateurs LDAP "Tata", "Titi" et "Toto"

- Chaque utilisateur est membre d'un des groupes LDAP "ENT-DOCS-R" ou "ENT-DOCS-W" (R pour lecture et W pour écriture, selon le type d'accès autorisé)

- Un partage appelé "ENT-DOCS" a été crée sur le Synology et les droits d'accès ont été définis avec les groupes LDAP "ENT-DOCS-R" en lecture et "ENT-DOCS-W" en lecture/écriture

Voici donc mes questions et remarques à ce sujet (enfin !!!) :

1. Le but est d'utiliser une commande KiXtart pour vérifier l'appartenance de l'utilisateur qui se connecte à un groupe afin de connecter ou non le lecteur concerné (Si "Toto" est membre du groupe "ENT-DOCS-R" ou "ENT-DOCS-W", alors connecter le lecteur "ENT-DOCS"). Directory Server n'étant pas un domaine à part entière (comme Samba ou ADS) mais un simple annuaire LDAP, les commandes COM ou ADSI utilisées habituellement depuis KiXtart ne fonctionnent pas. En utilisant Softerra LDAP Browser (http://www.ldapbrows...dap-browser.htm), j'arrive bien à me connecter à la base LDAP et à parcourir les données de Directory Server; la structure de l'information est donc connue et je sais où chercher les données dont j'ai besoin. Par contre, je ne sais pas comment faire depuis les commandes KiXtart pour vérifier l'appartenance de l'utilisateur à un groupe donné ????

Je ne suis pas forcément attaché à KiXtart (c'est juste que c'est ce qu'on a toujours utilisé jusqu'à présent), si vous pensez que je peux arriver au même résultat avec un autre langage de script je suis prêt à faire les efforts nécessaires pour m'adapter. Il faut toutefois que le script fonctionne aussi bien avec des serveurs Windows ADS que Linux Samba... les postes clients sont majoritairement sous Windows (XP ou Seven) !

2. Existe-t-il un moyen de gérer l'imprimante réseau depuis le Synology (franchement, je ne le crois pas) de sorte que les utilisateurs voient cette imprimante partagée depuis \\"Adresse_IP_du_Syno"\"Nom_de_partage_de_l'imprimante"; comme on peut le faire avec un serveur traditionnel ? Il faudrait donc que le Syno soit capable de stocker les fichiers de pilote pour chaque version d'OS (Linux, Win32, Win64, etc.) au moment de la création du partage de l'imprimante. L'idée étant que le script connecte automatiquement les imprimantes présentes lors de chaque connexion sans que l'utilisateur ait à soucier de quoi que se soit !

3. C'est pas une question, juste une remarque sur une limitation actuelle; mais je ne désespère pas que cela soit corrigé dans une future version de DSM. Lorsqu'on active le service d'accueil de l'utilisateur cela fonctionne bien pour les comptes locaux du Syno, par contre, le paramètre n'est pas appliqué sur les comptes du Directory Server. Il est donc impossible d'utiliser le partage "home" comme avec un compte local !

Ce n'est pas très grave puisque l'utilisation du script de connexion me permet d'avoir une alternative parfaitement adapté pour ce problème, mais je pense qu'il serait tout de même utile de voir cette fonction implémentée dans le DSM...

Merci à ceux qui auront pris la peine de lire jusqu'au bout et je donne tout ma gratitude à ceux qui auront, en plus, pris la peinde répondre smile.png !

PS : Je cherche surtout une solution pour le point 1... les 2 et 3 sont moins importants pour l'instant.

Partager ce message


Lien à poster
Partager sur d’autres sites

pour le point 3, il me semble que si tu actives le client ldap, tu as accès au service d'accueil pour les utilisateurs du directory server.

tu peux faire des requetes LDAP depuis du vbscript (ex trouvé sur google ... http://www.tek-tips.com/faqs.cfm?fid=5688)

Modifié par Brunchto

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci infiniment pour ta réponse Brunchto,

Au temps pour moi ! Tu as parfaitement raison pour le point 3, il faut effectivement activer l'accueil utilisateur au niveau des utilisateurs dans le LDAP client du Syno. Si j'avais bien activer le client LDAP (indispensable pour pouvoir utiliser la sécurité LDAP sur les partages du Syno), je n'avais pas remarqué le bouton "Accueil utilisateur" dans l'onglet des utilisateur LDAP !!! Encore merci, c'est parfait.

Pour ta deuxième remarque, c'est tout mon problème. On trouve sur le net des exemples à foison sur la manière de se connecter à une base LDAP, quelque soit le langage de script qu'on utilise. Le problème, c'est que tous ces exemples se basent sur des commandes ADSI qui, comme leur nom l'indique, se basent sur la structure d'Active Directory. La commande << GetObject("LDAP://rootDSE") >> en particulier, qui sert à déterminer la racine d'accès de LDAP, mais qui ne fonctionne que lorsqu'un domaine est présent (???) (cf. http://technet.microsoft.com/en-us/library/ee156506.aspx).

Je vais quand même essayer de creuser dans ce sens car je pense que cela devrait être faisable sans trop de problèmes (?). Il faut juste trouver les bonnes commandes et la syntaxe qui va bien !

Je posterai la syntaxe dès que cela marchera, mais si vous avez d'autres idées...

Partager ce message


Lien à poster
Partager sur d’autres sites

Cherchez plus, j'ai trouvé biggrin.png !

Voilà la syntaxe à utiliser en KiXtart :

$SrvFullName = "ldap.test.local" ; Correspond au FQDN du Directory Server, on peut aussi utiliser l'adresse IP du Syno

$LDAPRootFQDN = "dc=ldap,dc=test,dc=local"

Function InLDAPGroup($LDAPGroupName)

$LDAPGroupPath = "LDAP://" + $SrvFullName + ":389/cn=" + $LDAPGroupName + ",cn=groups," + $LDAPRootFQDN

$LDAPUsers = GetObject($LDAPGroupPath)

If @ERROR = 0

For each $Item in $LDAPUsers.memberUid

If ($Item == @USERID)

$InLDAPGroup = 1

Return

EndIf

NEXT

$InLDAPGroup = 0

EndIf

EndFunction

InLDAPGroup("ENT-DOCS-R") ; Le nom du groupe pour lequel tester l'appartenance de l'utilisateur connecté

En fait, la clé du problème se trouve dans "$LDAPUsers.memberUid", car ce paramètre est propre à la RFC utilisé par Directory Server pour sa structure LDAP. Avec AD, ce paramètre s'appelle "name" au lieu de "memberUid" ????

Si vous êtes dans un cas de figure similaire, je ne peux que vous conseiller d'utiliser un client LDAP (Softerra LDAP Browser dans mon cas) afin d'obtenir toutes les infos nécessaires. C'est en effet par ce biais que j'ai pu voir le nom des attributs utilisés....

A dispo si vous avez des questions !

Partager ce message


Lien à poster
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.