Tentative de connexion d’IMA sur son Datastore avec le compte ordinateur

En pleine préparation de la migration vers un SQL Server 2008, nous avons décidé de dire au revoir à ce bon vieux compte SA pour le remplacer par un compte de connexion ActiveDirectory sans privilège, comme nécessaire le compte avait les droits db_owner sur la base. De plus, nous lançons les services SQLServer avec un autre compte que le compte système locale.

Lors de la maquette, une fois le dsmaint migrate effectué, nous avons essayé d’ajouter un nouveau serveur dans le nouveau datastore. Et là, surprise! IMA essaie de se connecter au Datastore avec le compte Ordinateur (DOMAIN\COMPUTERNAME$)… Sans succès!

error_listerror

Même après un “dsmaint config”, IMA essayait de se connecter avec le compte Ordinateur. L’activation du mode verbeux de chfarm (chfarm /verbose) et l’activation des traces ODBC (onglet traçage) ne permettait d’obtenir des pistes sur cette erreur. Pire, les traces ODBC semblait indiqué une connexion sur une base de données :

MF20            13a8-13ac EXIT  SQLDriverConnectW  with return code 1 (SQL_SUCCESS_WITH_INFO)
          HDBC                00A21830
          HWND                00000000
          WCHAR *             0x4C017CD4 [      -3] "******\ 0"
          SWORD                       -3
          WCHAR *             0x4C017CD4
          SWORD                        2
          SWORD *             0x00000000
          UWORD                        0 <SQL_DRIVER_NOPROMPT>

          DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Le contexte de la base de données a changé ; il est maintenant 'MONDATASTORE'. (5701)

          DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Le paramètre de langue est passé à Français. (5703)

Comment résoudre le problème ?

Nous avons juste ajouter un spn (ServicePrincipalName) au compte de service utilisé pour lancer l’instance SQLServer.

Setspn -A MSSQLSvc/<SQL Server name>:1433 <domain>\<user>

Pourquoi ?

Un début de réponse :

In Configuration Manager 2007, it is supported to install the site database on a SQL Server named instance and not just the default instance as it was in SMS 2003. Regardless of whether or not you use the default or a named instance of SQL Server to host the site database, a Service Principal Name (SPN) must be registered for the SQL Server service account in Active Directory to enable Kerberos authentication.

When the SQL Server service account is configured to use the local system account, the server will automatically publish the SPN for you. However, a SQL Server best practice is to change the startup account from local system to a domain user account to better secure the SQL Server instance. If you’re using a domain user account to run the SQL Server service, you have to manually create the SPN for the account in Active Directory. Once created, you can view the SPNs registered using an ADSIEdit console.

http://myitforum.com/cs2/blogs/jgilbert/archive/2007/10/11/using-sql-server-named-instances-to-host-the-configuration-manager-site-database.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *