Discussion :

[qi130]

Après avoir fait le tour des posts évoquant la sécurité sous IB, je soulève cette question...sensible.

un user "lambda" doit être déclaré par un admin pour pouvoir se connecter à la base applicative.
A priori, pour cette connexion, on sollicite le serveur qui vérifie dans ISC4 que ce user est déclaré avec concordance du pass.

Mais, comment faire pour permettre à ce user de changer son mot de passe ?

Je pense qu'il est exclu de lui permettre de se connecter sur ISC4 en direct , alors comment faire ?

Peut-on procéder par une PS qui endosserait un rôle d'admin pour faire ce changement ?
Si oui, qu'elle serait la syntaxe de cette appropriation de rôle, et pour attaquer quelle base (y a t'il une sorte de variable système contenant l'adresse de ISC4, ou 1 référence logique à la table USERS ?) ?


Merci d'avance pour vos lumières...(exemples bienvenus )

[Benjamin GAGNEUX]

Salut,

Si c'est sous Delphi, regarde dans la Delphi, tu devrais trouver ton bonheur...

A+

[qi130]

Oui, j'ai bien vu un truc dans la FAQ, mais il exige 2 choses peu orthodoxes:
1/ laisser le tandem SYSDBA / masterkey (ou un autre administrateur) dans l'exec, et le premier petit malin avec un editeur hexa récupère les clés de la boutique...

2/ définir un admin permanent et identique à tous les sites d'installation d'une appli (je me vois mal recompiler sur chaque site)

En plus, ce genre de solution organisée coté client fait que le pass transite en clair sur le réseau.

Je sais qu'il existe une unité delphi (dont je dispose) permettant de crypter le pass coté client; d'où ma demande orientée PS afin de faire l'update direct de ISC4.GDB

[Barbibulle]

Pour ajouter/ou modifier un user il faut les droits admin.

Si vous ne voulez pas avoir votre mot de passe admin dans votre exe (ce qui est normal, car en cas de changement il faudrait recompiler) vous pouvez très bien le crypter dans la base des registre ou un fichier local (.ini par exemple).

En ce qui concerne le passage du mot de passe en clair sur le reseau. Une personne capable de l'intercepter aura les compétance de toute façon de s'en passer. En récupérant un backup ou la base elle même sur un autre poste sur lequel il vient d'installer un serveur IB/FB, (avec donc un isc4.gdb vierge) il pourra sans trop de probleme accèder aux objets de la base.


Maintenant vous pouvez modifier la base de sécurité pour en effet permettre un USER de modifier son mot de passe. Mais il vous faudra faire pas mal de controle avant car en donnant les droits de modification au USER lamda dans cette base risque de faire plus de mal que de bien. En effet s'il peut modifier cette base il peut du coup s'y connecter et pourquoi pas modifier les autres users et pourquoi pas le SYSDBA et son mot de passe .

Donc oui c'est possible mais il y a quelques procédures à respecter. Et celà pose le problème des mises à jours de IB/FB.
En effet par exemple fb1.5 et IB7.X n'utilisent pas le isc4.GDB mais respectivement le security.fdb et le admin.ib. Et la structure pourait très bien évoluer vous obligeant à maintenir une mise à jours de cette base que vous aurez modifié.


Voilà maintenant, c'est à vous de voir en fonction des risques si celà en vaut vraiment la peine.

[qi130]

Merci Barbibulle pour ces explications.

Je me permet simplement de revenir sur ma première requète concernant la possibilité pour une PS d'endosser un rôle d'administrateur pour effectuer un changement dans la table USERS.

Est-ce une vue de l'esprit ou est-ce possible ?

[Barbibulle]

Une PS se trouvant dans votre base ne peut pas se connecter à la base de sécurité *. Partant de là, ce n'est donc pas possible de modifier le password d'un USER avec une PS se trouvant dans une autre base.

Le seul moyen ** de modifier un password consiste à se connecter à cette fameuse base de sécurité qui par défaut n'est modifiable que par le SYSDBA....




*: Sauf en utilisant une UDF mais dans ce cas cette UDF devra se connecter à la base de sécurité en utilisant un compte admin. C'est ce que font les fonctions ADD_USER, Modify_user et delete_user de l'UDF Rfunc. On en revient donc au même point, il faut un compte admin...

** : Si on ne modifie pas la base de sécurité, c'est le seul moyen.
En modifiant la base de sécurité on peut faire en sorte qu'un user puisse modifier son mot de passe. Mais là comme je l'ai dit à chaque changement de version de fb/IB il faut regarder si la base de sécurité est modifiée ou non pour adapter les changements que vous aurez fait.

[Barbibulle]

Donc pour résumer et pour être plus clair les 3 seuls moyens pour modifier un USER sont :

A/ Depuis votre appli, utiliser les API/composants standards ou même les outils d'administration (IBConsole, gsec). Dans ce cas il faut utiliser un compte ADMIN et donc connaitre son mot de passe. => vous pouvez crypter le mot de passe (dans un fichier ou base des registre ou plus astucieusement dans votre base) mais il transitera sur le reseau en clair.

B/ Une variante de A/ Vous créez une PS dans votre base qui va utiliser la fonction Modify_USER de l'UDF RFUNC. Dans ce cas aussi il faut utiliser un compte Admin. => Vous pouvez crypter le mot de passe dans une de vos table de paramètrage. L'avantage par rapport à A/ c'est que le mot de passe ne transite pas sur le réseau, il se trouve uniquement sur le serveur. Donc en cas de changement de mot de passe de l'ADMIN vous n'avez qu'à le changer dans votre base (alors que dans A/ il faut changer sur tous les postes le paramétrage s'il est stoqué en local).

C/ Modifier la base de sécurité pour permettre un USER de modifier uniquement son compte. => Plus besoin d'un compte admin pour modifier un user. On peut utiliser les outils standards/API/composant pour modifier le USER mais au lieux d'utiliser un compte admin vous pourrez utiliser le compte du USER pour qu'il modifie ses données. Dans les point négatifs : Obligation lors de mise à jours d'IB/FB de regarder si vos modifs peuvent s'appliquer ou non.

[qi130]

Super-explications


Je crois que nous avons fait le tour du problème, cela mérite de figurer dans la

Merci infiniment