J'ai une application de fonction à laquelle est attribuée une identité gérée attribuée par l'utilisateur , et il l'utilise pour se connecter à la base de données SQL. Cela fonctionnait bien pendant quelques jours, mais a soudainement cessé de fonctionner, sans aucune modification de la base de données ou de l'application de fonction.
CREATE USER [<Name of user assigned identity>] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [<Name of user assigned identity>]; ALTER ROLE db_datawriter ADD MEMBER [<Name of user assigned identity>];
J'ai cherché en ligne et j'ai trouvé façons de rechercher une erreur plus détaillée dans sys.event_log . En conséquence, je vois que l'erreur est 18456 et que l'état est 68. Malheureusement, l'état 68 pour l'erreur 18456 n'est documenté nulle part. ( Document officiel ).
Voici comment je crée une SqlConnection (et notez que cela fonctionnait avant, et que le même code fonctionne ailleurs dans la même configuration exacte):
SqlConnection connection = new SqlConnection("Server=tcp:myserver.database.windows.net,1433;Database=MyDb;");
connection.AccessToken = await new AzureServiceTokenProvider("RunAs=App;AppId=<ClientId>").GetAccessTokenAsync("https://database.windows.net/");
L'utilisateur a été créé dans db en utilisant:
Error: Login failed for user '<ClientId>@<TenantId>'.
Tout pointeur vers où je peut regarder dans la suite?
Remarque:
3 Réponses :
Pour tirer parti d'une identité attribuée par l'utilisateur, vous devrez fournir une configuration supplémentaire. Veuillez consulter prise en charge de la chaîne de connexion pour la bibliothèque AppAuthentication .
Lors de la création de l'utilisateur SQL, veillez à utiliser le nom de la ressource d'identité attribuée par l'utilisateur plutôt que le nom du site.
J'utilise cette chaîne de connexion (voir la question ci-dessus). Je viens également de mettre à jour la question et d'ajouter l'instruction SQL qui a été utilisée pour créer l'utilisateur.
Le service auquel l'identité gérée est liée a-t-il été supprimé et recréé? Si tel est le cas, l'empreinte numérique dans Azure AD a changé, ce que reconnaît SQL Server. Malheureusement, c'est probablement l'un des rares inconvénients des identités gérées avec des bases de données SQL et, à ma connaissance, le seul service qui l'exige. Essayez de supprimer et de recréer l'utilisateur et voyez si cela fonctionne.
À l'avenir, si vous effectuez des déploiements CI / CD, il serait avantageux d'avoir un simple script SQL pour supprimer et recréer l'utilisateur dans la base de données chaque fois que le service qui y est connecté est redéployé.
Tels que:
BEGIN
DROP USER [MSI NAME]
CREATE USER [MSI NAME] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [MSI NAME];
ALTER ROLE db_datawriter ADD MEMBER [MSI NAME];
END
GO
L'identité gérée n'a pas été supprimée ni recréée. J'ai essayé l'utilisateur drop et créer un utilisateur et cela ne semble pas aider - même erreur. Une autre chose étrange est que j'ai aussi un autre utilisateur contenu créé avec CREATE USER [name] WITH PASSWORD = '. Cela ne fonctionne plus non plus (même si je peux voir cela, et l'identité gérée dans Users in db). Je pense que quelque chose s'est mal passé avec la base de données. Cette base de données fait partie d'un groupe de basculement et j'utilise toujours l'URL principale du groupe de basculement pour me connecter. Et je peux confirmer qu'il n'y a pas eu de basculement automatique ou manuel.
J'ai remarqué quelque chose de très bizarre . J'ai donc essayé cette connexion d'authentification SQL (l'utilisateur contenu que j'ai expliqué ci-dessus). Cela ne fonctionne pas lorsque vous utilisez serveur = principal, mais fonctionne lorsque serveur = secondaire. J'imagine que la même chose se produirait avec l'identité gérée aussi. Donc, pour une raison quelconque, les mécanismes d'authentification de la base de données primaire ont été sérieusement perturbés. Je pense faire un basculement, puis un basculement pour faciliter les choses.
Ouais. Un problème est survenu avec le serveur. J'ai fait un basculement. Et puis arrêté la réplication, puis supprimé le serveur problématique. Et puis recréé le serveur et reconfiguré le groupe de basculement, qui a recréé la base de données. Et cela a fonctionné. Notez que la simple suppression de la base de données et la reconfiguration de la réplication pour recréer cette base de données n'ont pas aidé. La même erreur s'est produite. J'ai dû me débarrasser du serveur problématique. Je ne sais pas ce qui s'est passé, mais quelque chose a été gâché dans le serveur SQL. J'ai vérifié que les règles du pare-feu n'avaient pas changé et qu'il n'y avait rien dans le journal d'activité au cours de la dernière semaine. donc pas sûr de ce qui s'est passé.
Je n'ai pas pu trouver la cause principale, mais je publie ce qui m'a aidé à être débloqué afin que, espérons-le, cela aidera d'autres personnes à l'avenir.
Pour une raison quelconque, toute forme d'authentification (sauf par l'administrateur AAD du serveur ) échouaient sur ce serveur. Ainsi, non seulement l'authentification de l'identité attribuée à l'utilisateur a échoué (qui est décrite dans la question ci-dessus), mais également utilisateur contenu a échoué. La suppression de l'identité attribuée à l'utilisateur de la base de données et la réajout n'ont pas fonctionné:
DROP USER [ContainedUser]; CREATE USER [ContainedUser] WITH PASSWORD='******'; ALTER ROLE db_owner ADD MEMBER [ContainedUser];
De même, la suppression de l'utilisateur contenu et la recréation n'ont pas fonctionné non plus.
DROP USER [<Name of user assigned identity>]; CREATE USER [<Name of user assigned identity>] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [<Name of user assigned identity>]; ALTER ROLE db_datawriter ADD MEMBER [<Name of user assigned identity>];
J'ai également remarqué que le secondaire (c'est-à-dire la réplique) fonctionnait bien et que l'authentification fonctionnait contre lui. Donc, fondamentalement, j'ai conclu que quelque chose ne va pas avec mon primaire, je ne sais pas exactement quoi.
J'ai donc décidé de recréer la base de données:
Donc, vous avez d'autres applications de fonction (avec différents clientid) qui fonctionnent correctement en utilisant cette méthode, c'est juste celle-ci qui pose le problème? Je suggère que, dans un premier temps, vous supprimiez et recréiez l'utilisateur dans SQL Server. Pour être clair, cette chaîne de connexion utilise "Identité affectée par l'utilisateur" et non "Identité gérée".
@ Nick.McDermaid J'ai une autre application de fonction avec une identité assignée à un utilisateur différent qui parle à une autre base de données. Le code pour les deux applications est le même, le schéma de base de données est le même. Fondamentalement, on est la mise en scène, on est prod. Prod travaille toujours. La mise en scène a cessé de fonctionner soudainement même en l'absence de changement. L'identité attribuée à l'utilisateur est l'ID client d'une identité gérée créée dans Azure Portal et attribuée à l'application de fonction.