Guide de sécurité dans Microsoft Dynamics SL 7.0 non officiel


Ce document est fourni comme-est et est destinée à vous aider à comprendre la structure de la sécurité des bases de données 7.0 de SL. Bien que remarques sont les bienvenues sur ce document, les erreurs ou omissions ne constituent pas un défaut du produit.  

Les informations contenues dans ce document est fourni en observant la structure de la base de données dans SQL Management Studio et de l’exécution de traces de différents processus dans le Générateur de profils SQL. Aucune information dérivée de code source compilé est incluse.

Sauf indication contraire, les informations contenues dans ce document suppose l’utilisation de « Authentification Windows ».

 

 

Contenu :

Les utilisateurs SQL et les rôles :

07718158D19D4f5f9D23B55DBF5DF1- Également connu sous le nom « le superutilisateur entité ». Ce compte doit apparaître comme étant désactivés.  Cette connexion est créée par la Maintenance de la base de données « non interactive », qui signifie que vous ne pouvez pas vous connecter avec ce compte de connexion.  Il est uniquement utilisé pour l’emprunt d’identité dans SL.

Ce pseudo est utilisé lorsqu’une seule procédure stockée doit accéder aux objets dans la base de données système de SL et Application de SL. La procédure stockée de pp_cleanwrkrelease est un bon exemple. Cette procédure exécute une instruction delete à partir d’une table dans la base de données de l’Application de SL en fonction des informations contenues dans le tableau accès de la base de données système de SL. (La procédure stockée obtient à la table d’Access à l’aide de la vue VS_Access dans la base de données de l’application). De façon au sein de la procédure, une instruction qui ressemble à ceci :

AVEC EXECUTE AS '07718158D19D4f5f9D23B55DBF5DF1'

Cela signifie qu’au lieu d’utiliser notre connexion windows qui obtient ses droits du rôle d’application MSDSL, nous allons emprunter l’identité de l’utilisateur 07718158D19D4f5f9D23B55DBF5DF1 lors de l’exécution de cette proc un. cela est nécessaire car les rôles d’application SQL (comme MSDSL) ne fonctionnent pas sur les bases de données. Si l’emprunt d’identité « Exécuter » n’a pas été utilisé, nous recevions de l’erreur suivante :

---------------------------
SQL Server Message 916
---------------------------
Le serveur principal « domaine\nom_utilisateur » n’est pas en mesure d’accéder à la base de données « SLSYS » dans le contexte de sécurité actuel.
---------------------------
OK  
---------------------------

L’utilisateur 07718158D19D4f5f9D23B55DBF5DF1 a accès à la plupart des vues vs_ et quelques tables dans la base de données des applications de SL et la plupart des tables de la base de données système de SL. 07718158D19D4f5f9D23B55DBF5DF1 utilisateur ou l’emprunt d’identité se rapporte également vers le propriétaire de la base de données en raison de chaînage. Le propriétaire des bases de données système de SL et Application de SL doivent correspondre... Si ce n’est pas le cas, vous obtiendrez cette erreur :

---------------------------
SQL Server Message 916
---------------------------
Le serveur principal « 07718158D19D4f5f9D23B55DBF5DF1 » n’est pas en mesure d’accéder à la base de données « SLSYS » dans le contexte de sécurité actuel.
---------------------------
OK  
---------------------------

Il ne semble pas peu importe qui est le propriétaire de la base de données tant que l’ensemble de votre Application de SL et bases de données système de SL ont le même propriétaire. Reportez-vous à la section « Propriétaire de la base de données » section pour plus d’informations. Voir aussi http://msdn2.microsoft.com/en-us/library/ms188676.aspx Pour plus d’informations sur le chaînage.

 

E7F575915A2E4897A517779C0DD7CE- Également appelé « L’état utilisateur ». Ce code d’utilisateur est utilisé parallèlement à la connexion ODBC et de votre nom d’utilisateur windows pour exécuter Crystal Reports. L’utilisateur semble avoir les droits SELECT pour toutes les tables et les vues et les autorisations d’exécution à toutes les procédures stockées dans les bases de données système de SL et Application de SL.  

L’utilisateur doit disposer des droits de sélectionner et d’exécution pour les objets personnalisés utilisés dans un rapport personnalisé ou si vous obtenez l’erreur suivante :

---------------------------
Application d’auxiliaire de rapports Crystal pour Solomon IV
---------------------------
Échoué de la requête Get SQL

Rapport : C:\Program Files\Microsoft Dynamics SL\Usr_Rpts\03730DET. RPT

Erreur du moteur d’impression de Crystal : 709 - Erreur dans le fichier C:\Program Files\Microsoft Dynamics SL\Usr_Rpts\03730DET. RPT :

La table est introuvable.
---------------------------
OK  
---------------------------

Si le compte est désactivé ou si le mot de passe a été modifié, vous obtiendrez l’erreur suivante lors de l’exécution d’un rapport :

---------------------------
Application d’auxiliaire de rapports Crystal pour Solomon IV
---------------------------
Échoué de la requête Get SQL

Rapport : C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01650.RPT

Erreur du moteur d’impression de Crystal : 536 - erreur dans le fichier C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01650.RPT :

Impossible de se connecter : paramètres ouverture de session incorrecte.
---------------------------
OK  
---------------------------

 

MASTER60SP- L’utilisateur principal de SL 6.0 SP1 - modèle de sécurité SL 6.5. Cet utilisateur est toujours utilisé si 7.0 SL sous « Authentification SQL » en cours d’exécution. Dans une base de données authentifié par windows, cet utilisateur n’existe pas en général et n’est pas utilisé. L’utilisateur est à peu près l’équivalent de l’utilisateur « Master » dans SL 6.0 et plus anciens.

Dans une base de données authentifiées de non windows, l’utilisateur master60sp est le propriétaire de la base de données SL Application et système de SL, en lui donnant un contrôle total sur tous les objets dans ces bases de données. Toutes les interactions entre les écrans de SL et le rapports s’effectue via l’utilisateur master60sp... l’utilisateur windows ID n’est pas utilisé du tout. Le mot de passe de cet utilisateur peut être modifié en ouvrant l’écran d’Administration de base de données (98.270.00) dans SL.

L’utilisateur est toujours utilisée dans FRx. cela peut poser un problème car dans une base de données windows authentifiés, l’utilisateur master60sp n’existe pas. 941591 de la base de connaissances explique comment contourner ce problème.

 

Utilisateur de la CD7359B5576446f85EB67E824B4770- Modèle de sécurité de l’utilisateur « préconnexion » à partir de la SP1 6.0 SL - 6.5 de . Cet utilisateur est également utilisé si 7.0 SL sous « Authentification SQL » en cours d’exécution. Dans un serveur 7.0 SL windows authentifié de base de données, cet utilisateur n’existe pas en général et n’est pas utilisé. L’utilisateur est à peu près l’équivalent de l’utilisateur « MasterRO » dans SL 6.0 et plus anciens.

L’utilisateur n’a accès à la base de données système. Il ne doit comporter que des droits sur la base de données de l’application, ou vous pouvez obtenir le problème décrit dans la base de connaissances 896321. Il peut sélectionner à partir de plusieurs tables et exécuter plusieurs procédures stockées. Il peut également mettre à jour/Insérer/supprimer dans les tables rptextra et de domaine.  

Au cours du processus d’ouverture de session, l’utilisateur CD7359B5576446f85EB67E824B4770 effectue les tâches suivantes :

  • Vérifie la version de SQL
  • Vérifie la version de la base de données de SL
  • Recherche les clés d’enregistrement
  • Obtient une liste de sociétés dans la base de données
  • Transmet le traitement à l’utilisateur de master60sp

 

Rôle de base de données de la MSDynamicsSL- SL tous les utilisateurs sont un membre de ce rôle. Le rôle dans la base de données système de SL dispose des autorisations d’exécution à la getAuthenticationType, GetInfo, et getVersion des procédures stockées dans la base de données système. Le rôle dans la base de données des applications de SL ne dispose pas des autorisations. Le but de ce rôle est utilisé dans la base de données de l’Application de SL n’est pas connu. Si les utilisateurs ne sont pas un membre du rôle de base de données MSDynamicsSL sur le système de SL ou de base de données si le rôle de base de données MSDynamicsSL sur le système de SL ne dispose pas de l’autorisation EXECUTE pour le getauthenticationtype procédure stockée, puis entrée. EXE s’arrête lorsque des non-administrateurs tentent de connexion à SL.

 

Rôle d’Application MSDSL- Ce rôle possède les droits de contrôle sur tous les objets dans la base de données.  

L’importance de ce qui est un rôle de « application » au lieu d’un rôle de « base de données « normal est que ces droits sont uniquement valides lorsque l’accès à la base de données à partir de l’applicationSL. , Même si l’utilisateur peut avoir des droits pour ajouter un nouveau compte à l’écran graphique de gestion des comptes à l’intérieur de SL, ils n’auront pas de droits pour exécuter une commande d’insertion dans la table compte alors que SQL Server Management Studio.

Le rôle est spécifique de la base de données... c'est-à-dire le MSDSL rôle dans une base de données n’est pas le même rôle que le rôle MSDSL dans une autre base de données même si elles sont nommées de la même chose. Le rôle de « MSDSL » dans la base de données des applications de SL a des droits de contrôle sur les objets de cette base de données. Et le rôle de « MSDSL » dans la base de données du système de SL dispose de droits de contrôle sur les objets dans la base de données système.  

Si ce rôle, le mot de passe est incorrect, il peut provoquer l’erreur suivante lors de la connexion (la propriété de la synchronisation et le scénario de sécurité corrigera ce sauf s’il existe plusieurs SL bases de données qui pointent vers la même base de données d’application) :

---------------------------
CONNEXION
---------------------------
L’erreur fatale SQL 15161 s’est produite lors de l’ouverture de la société
---------------------------
OK  
---------------------------

Si le scénario de synchronisation ne corrige pas l’erreur, puis vous devez manuellement passer par chaque base de données sur le serveur SQL et exécutez la commande suivante pour voir si s’il existe plusieurs bases de données système en pointant sur la même base de données d’application.  Vous devez être supprimés ou au moins aimez plus à partir de l’application de base de données si vous trouvez que ce soit le cas, une seule des bases de données du système.

selectDatabaseName, * Dedomaine
selectDatabaseName, * Desociété

Domaine\nom d’utilisateur- Une autre modification dans 7.0 est que logins windows de l’utilisateur sont maintenant ajoutées à la base de données SQL. Vous pouvez le voir dans Management Studio de SQL en développant sur une base de données SL -> sécurité -> utilisateurs. Les comptes d’utilisateurs ne sont pas eux-mêmes des droits d’accès ; ils obtenir quelques droits en étant un membre du rôle MSDynamicsSL, mais que les droits sont accordés principalement par SL avec le rôle d’application MSDSL. L’exception est si l’utilisateur est un membre du groupe Administrateurs de SL. Voir la discussion dans « Groupes SL » ci-dessous pour plus d’informations.

En utilisant les comptes d’utilisateurs dans SQL, les utilisateurs ont l’autorisation pour se connecter à SQL Server Management Studio sans avoir à connaître le mot de passe « sa ». Heureusement car les rôles d’application sont utilisés, n’ont pas l’autorisation réellement rien à faire lorsque vous êtes connecté po

 

BusinessPortalUser- De SQL Server cet utilisateur est créé lors de l’installation du portail d’entreprise. Qu’il est utilisé pour l’interaction entre business portal et SQL. Il n’a aucun droit qui lui sont propres. Il obtient sa puissance d’être un membre du rôle de base de données BFGROUP.  

 

Rôle de base de données BFGROUP- Ce rôle est utilisé pour accorder des autorisations « SELECT, UPDATE, INSERT, DELETE » à tous les objets de SL. Le BusinessPortalUser doit être le seul membre de ce rôle. Parfois le rôle ne possède pas les droits d’accès à des objets différents qui peuvent provoquer des erreurs dans portail d’entreprise. Pour plus d’informations, consultez KB 906715.

Groupes de SL :

Groupe d’administrateurs- Comme son nom l’indique, un membre de ce groupe donne à l’utilisateur des privilèges d’administrateur dans les SL. n’importe quel membre du groupe est l’équivalent de l’utilisateur « SYSADMIN » dans les versions antérieures. Des droits individuels ne sont pas affectées au groupe « Administrateurs » dans l’écran de Maintenance de droits d’accès... à la place est automatiquement membre de ce groupe donne tous les droits sur tous les écrans et les États.

Un membre du groupe Administrateurs fournit également quelques privilèges supplémentaires :

  • Seuls les administrateurs seront affiche le groupe de module standard « Administration » dans le menu
  • Seuls les administrateurs peuvent ajouter de nouveaux utilisateurs au système
  • Les administrateurs reçoivent également automatiquement le rôle de serveur « sysadmin » sur le SQL Server. Ce point est important à savoir parce que l’utilisateur sera désormais en mesure de vous connecter à SQL Server Management Studio et effectuer toutes les tâches sur une base de données.
    • Remarque : Jusqu'à débat si ceci est améliorée ou modifiée dans 7.0 Fp1 avec « accorder cette autorisation de l’utilisateur pour créer des utilisateurs et des comptes de connexion SQL server »

De ce fait, l’appartenance à ce groupe doit être limité aux seuls utilisateurs qui en ont absolument besoin.

 

Groupe tout le monde- Contraire à ce que son nom l’indique, tous les utilisateurs ne sont pas automatiquement membre de « tout le monde » groupe. Vous devez manuellement ajouter de nouveaux utilisateurs pour tout le monde groupe. Par défaut, ce groupe est utilisé pour fournir aux utilisateurs le menu standard. Le groupe ne fournit pas de droits d’accès par défaut.

La synchronisation de tous les privilèges et scénario de mise à jour de sécurité :

Ce scénario de Maintenance de base de données (98.290.00) peut résoudre de nombreux problèmes et doit être la première étape de résolution des problèmes de sécurité ou connecter problème connexe. Lorsque le scénario est exécuté, il synchronise toutes les bases de données sur le serveur, que l’un est sélectionné dans la maintenance de la base de données. Voici les détails sur ce que fait le processus :

· Windows authentifié de bases de données

o   Définit le propriétaire de la base de données

§  Dans 7.0, le propriétaire est fixé à l’ouverture de session ID utilisé pour vous connecter à la maintenance de la base de données.  

§  7.0 SP1 le propriétaire a la valeur « sa »

o   Crée les 07718158D19D4f5f9D23B55DBF5DF1 et les utilisateurs de E7F575915A2E4897A517779C0DD7CE sur le SQL Server uniquement si elles sont manquantes.

o   Supprime, puis ajoute l’utilisateur de E7F575915A2E4897A517779C0DD7CE des bases de données système de SL et Application de SL.

o   Accorde des droits à l’utilisateur de E7F575915A2E4897A517779C0DD7CE.

o   Accorde des droits à l’utilisateur de 07718158D19D4f5f9D23B55DBF5DF1.

o   Définit la propriété digne de confiance sur les bases de données système de SL et Application de SL sur TRUE.

o   Crée le rôle de base de données MSDynamicsSL s’il est manquant et lui attribue des droits, mais ré-n’ajoute pas les utilisateurs au rôle. Voir bogue 15135.

§  Dans SL 7.0, il seulement crée de nouveau le rôle de la base de données système de SL

§  Dans SL 7.0 Sp1, il recrée le rôle sur les bases de données système de SL et Application de SL.  

o   Crée le rôle d’application de MSDSL sur le système et les applications de bases de données uniquement si elles sont manquantes

o   Attribue des droits au rôle MSDSL dans le système de base de données. Bogue 15053, les droits ne sont pas attribués au rôle MSDSL dans la base de données d’application si le rôle a été absent. Cela peut conduire à un Message système 10232 à la connexion. Bogue voir pour la solution de contournement.

o   Réinitialise et synchronise le mot de passe du rôle application MSDSL.

o   Réinitialise le mot de passe E7F575915A2E4897A517779C0DD7CE.

o   Réinitialise le mot de passe 07718158D19D4f5f9D23B55DBF5DF1.

· SQL authentifié de bases de données

o   Définit le propriétaire des bases de données système de SL et Application de SL à master60sp.

o   Crée l’utilisateur master60sp sur le serveur, s’il est manquant.

o   Crée l’utilisateur CD7359B5576446f85EB67E824B4770 s’il est manquant.

o   Supprime, puis ajoute l’utilisateur de CD7359B5576446f85EB67E824B4770 des bases de données système de SL et Application de SL.

o   Accorde des droits à l’utilisateur de CD7359B5576446f85EB67E824B4770.

o   Définit la propriété digne de confiance sur les bases de données système de SL et Application de SL sur TRUE.

o   Permet de synchroniser le mot de passe master60sp.

o   Réinitialise le mot de passe CD7359B5576446f85EB67E824B4770.

Propriétaire de la base de données :

Le propriétaire de la base de données obtient défini lors de la maintenance de base de données (98.290.00). Dans la version 6.0 Service Pack 1 – 6.5 ou 7.0 de SL à l’aide de l’authentification SQL, le propriétaire de la base de données est master60sp. Dans SL 7.0, le propriétaire des bases de données va prendre la valeur l’ID d’utilisateur pour vous connecter à la maintenance de la base de données. Dans SL 7.0 Service Pack 1, le propriétaire des bases de données va prendre la valeur sa.

Le propriétaire de la base de données hérite d’un contrôle total sur tous les objets dans la base de données. Généralement peu importe qui le propriétaire des bases de données sont tant que le même utilisateur possède toutes les bases de données de SL. Est une exception à cette règle. Si le propriétaire de la base de données est un utilisateur de domaine et pour une raison quelconque le SQL Server a des difficultés à contacter un contrôleur de domaine, vous pouvez voir le message d’erreur suivant dans différents emplacements :

---------------------------
Message de SQL Server 15404
---------------------------
N’a pas pu obtenir d’informations sur Windows NT groupe/utilisateur 'Domaine\nom_utilisateur', code d’erreur 0x54b.
---------------------------
OK  
---------------------------

Afin de devenir le propriétaire de la base de données, vous ne pouvez pas déjà être un utilisateur dans cette base de données. Est susceptible de provoquer l’erreur suivante dans la Maintenance de la base de données :

---------------------------
9829000
---------------------------
SetOwner erreur-2147206394 : [Microsoft] [pilote ODBC SQL Server] [SQL Server] le nouveau propriétaire proposé pour la base de données est déjà un utilisateur ou un alias dans la base de données.
---------------------------
OK  
---------------------------

Pour plus d’informations sur cette erreur, reportez-vous à la section 942450 de la base de connaissances.

Pour éviter ce problème, il est recommandé de rendre le propriétaire des bases de données à un utilisateur SQL comme « sa » (ce qui se produit automatiquement dans 7.0 Service Pack 1)

 

 

Divers :

Compte de Service SQL Server. Le compte de service peut être un compte, mais il doit avoir des autorisations de lecture sur les objets de compte d’utilisateur dans active directory. Sinon vous obtiendrez le message d’erreur suivant lorsque vous tentez d’ajouter des utilisateurs à SL :

---------------------------
Message de SQL Server 15404
---------------------------
N’a pas pu obtenir d’informations sur Windows NT groupe/utilisateur 'Domaine\nom_utilisateur', code d’erreur 0x54b.
---------------------------
OK  
---------------------------

Le compte de Service SQL Server peut être défini en cliquant sur Démarrer -> Paramètres -> Panneau de configuration -> Outils d’administration -> Services. À « SQL Server (MSSQLSERVER) », droite de défilement, cliquez sur et sélectionnez Propriétés. Puis cliquez sur l’onglet connexion.

Des connexions ODBC. Lorsque vous exécutez un rapport crystal dans une nouvelle station de travail, une connexion ODBC est créée pour les bases de données système de SL et Application de SL dans l’onglet DSN utilisateur de Sources de données (ODBC). Cette connexion doit être définie pour utiliser l’authentification SQL, même si vous utilisez l’authentification Windows pour se connecter à Dynamics SL. si cette connexion est modifiée pour utiliser l’authentification windows ou d’un DSN système est ajouté et qu’il utilise l’authentification windows, les utilisateurs peuvent voir le message d’erreur suivant :

---------------------------
Application d’auxiliaire de rapports Crystal pour Solomon IV
---------------------------
Échoué de la requête Get SQL
Rapport : C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01720.RPT
Erreur du moteur d’impression de Crystal : 709 - Erreur dans le fichier C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01720.RPT :
La table est introuvable.
---------------------------
OK  
---------------------------

, Il est recommandé de supprimer les entrées de l’onglet DSN utilisateur comme ils seront automatiquement recréés. Vous pouvez afficher les écritures en cliquant sur Démarrer -> Panneau de configuration -> Outils d’administration -> des Sources de données (ODBC).

 

La propriété « Fiable » sur la base de données. Cette opération semble être un nouvel élément dans SQL 2005. Lorsqu’une base de données est d’abord attaché à un SQL Server, la propriété « digne de confiance » sur la base de données est définie sur FALSE. Cela signifie que tous les objets dans la base de données qui tentent d’accéder aux objets dans une base de données (par exemple, l’affichage de la vs_company dans la base de données de l’Application de SL) échouera. Cela peut provoquer l’erreur suivante dans différents endroits, y compris l’ouverture simplement les écrans dans SL :

---------------------------
SQL Server Message 916
---------------------------
Le serveur principal « 07718158D19D4f5f9D23B55DBF5DF1 » n’est pas en mesure d’accéder à la base de données « SLSYS » dans le contexte de sécurité actuel.
---------------------------
OK  
---------------------------

Vous pouvez voir l’état actuel de la propriété à partir de SQL Server Management Studio -> droite cliquez sur la base de données -> sélectionnez Propriétés -> cliquez sur Options. Fiable de la propriété est dans la section divers.  

Le scénario de maintenance de base de données propriétaire de tous les synchroniser et de la sécurité s’affiche pour la définir à TRUE pour toutes les bases de données de SL.

Vous trouverez ici des informations plus :

http://msdn2.microsoft.com/en-us/library/ms187861.aspx

 

Ajout d’utilisateurs dans l’écran de Maintenance de l’utilisateur. Même si un utilisateur est mise à jour, insérer, supprimer des droits à l’écran de maintenance utilisateur (98.260.00), ils ne peuvent pas encore ajouter de nouveaux utilisateurs ou ajouter des utilisateurs au groupe Administrateurs. Lorsque vous essayez d’entrer le nom d’utilisateur Windows et quittez, vous recevrez l’erreur suivante :

---------------------------
SQL Server Message 229
---------------------------
L’autorisation d’exécution a été refusée sur l’objet 'xp_logininfo', base de données 'mssqlsystemresource', schéma 'sys'.
---------------------------
OK  
---------------------------

Si vous essayez d’ajouter un utilisateur au groupe Administrateurs, vous recevrez l’erreur suivante :

---------------------------
SQL Server Message 15247
---------------------------
Utilisateur ne dispose pas de l’autorisation d’effectuer cette action.
---------------------------
OK  
---------------------------

Vous devez être dans le groupe Administrateurs de SL pour ajouter des utilisateurs ou ajouter des utilisateurs au groupe Administrateurs. Lorsque vous ajoutez un nouvel ID d’utilisateur, le processus ajoute en fait l’utilisateur windows sous la forme d’un nouvel utilisateur SQL Server. Cela requiert un niveau élevé de droits SQL qui n’accorde pas au rôle MSDSL uniquement. Et vous devez être dans le groupe Administrateurs de SL.

 

Déplacement des bases de données vers un nouveau serveur. Dans une base de données authentifié par windows, chaque connexion de windows utilisateurs ID sont ajoutés à la SQL Server sous SQL Server -> sécurité -> connexions. Ces connexions sont ensuite ajoutées à la base de données sous SLDATABASE -> sécurité -> utilisateurs. , Mais si vous sauvegardez une base de données et le restaurer vers un nouveau serveur, les ID de connexion ne sont pas automatiquement ajoutés pour le SQL Server. Désormais l’ID de connexion de la base de données sont orphelins. Voir bogue 15024 qui doit être corrigé dans 7.0 Feature Pack 1. Pour corriger ce problème, vous devez exécuter le script suivant sur la base de données système SL sur le nouveau serveur. Si vous ne le faites pas, les utilisateurs recevront « connexion. EXE a rencontré un problème et doit fermer. Veuillez nous excuser pour la gêne occasionnée » erreurs lors de la connexion

déclarer @windowsuseracct comme char(85)
déclarer @execString comme char(200)
DÉCLARER user_cursor de curseur
sélectionnez windowsuseracct distinct à partir d’userrec
gauche de jointure sys.server_principals slogins sur userrec.windowsuseracct=slogins.name
où windowsuseracct <>'' et slogins.name est null
       OPEN user_cursor
Extraction suivante à partir d’user_cursor dans @windowsuseracct
En @@FETCH_STATUS = 0
       BEGIN
la valeur @execString = 'CREATE LOGIN' + QUOTENAME (rtrim(@windowsuseracct)) + 'À partir de WINDOWS avec DEFAULT_DATABASE = [master]'
              exec (@execString)
Extraction suivante à partir d’user_cursor dans @windowsuseracct
       END
User_cursor fermer
DEALLOCATE user_cursor