Bien que l'utilisateur DOM\U2 soit défini comme compte de proxy de
l'agent SQL Server SERVER2, une étape AX d'un travail défini sur
SERVER2 est éxécutée dans le contexte de sécurité de compte de proxy de
SERVER1 (qui est DOM\U1) !!!!!
Si SERVER1 est arrété alors le travail echoue, et dans le détail de
l'étape, cette erreur apparait : Impossible de définir un contexte
d'utilisateur proxy (raison : Paramètre incorrect). L'étape a échoué.
Si SERVER1 est démarré, alors le travail est exécuté sans pb et le
détail de l'étape est : Exécuté en tant qu'utilisateur : DOM\U1.
L'étape n'a produit aucun résultat. L'étape a réussi.
Est-ce un comportement normal ?
Est-ce que cela vient du fait que SERVER1 a été MSX et SERVER2 TSX (
SERVER2 n'est plus maitenant TSX) ? Ou est stockée l'info de compte
proxy ? Dans la BDR ?
Je n'ai trouvé d'info dans le BOL sur ces points, alors si vous avez
une idée ...
Cyril
br
"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message
news:Usenet.rnpofhpa@localhost...
br
"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message
news:Usenet.dhcdqtko@localhost...
--
J'ai peut-être raison.... j'ai peut-être tort,
on peut en discuter, sans se mettre à mort !
.oO Le Furax Oo.
Un autre problème qui est peut être en rapport :
définition le compte proxy de l'agent SQL.
- Lorsque le Compte d'ouverture de session de MSSQLSERVEUR est
différent de DOM\administrateur, il est impossible de définir le compte
proxy de l'Agent SQL (avec EM ou EXEC master.dbo.
xp_sqlagent_proxy_account N'SET',
N'DOM',
N'toto',
N'titi' )
L'erreur est la suivante :
Error executing extended stored procedure: Specified user can not login
Et ce avec un Compte d'ouverture de session de MSSQLSERVEUR : DOM\zozo
qui est membre des groupes BUILTIN\administrateurs et DOM\Admins du
domaine.
br
"Furax" <"Furax" power...@laposte.net> wrote in message
news:3cd6...@news.microsoft.com...
a+
br
"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message
news:Usenet.ieckjbtr@localhost...
1) Je fais quoi au juste ?
Je vérifie le contexte de sécurité dans lequel s'execute une étape de
type AX ou cmd_exec.
2) Plateformes
SERVER1 : 2000SRV AD 1er Controleur de domaine
SQL2000ENT SP2
Compte d'ouverture de session de MSSQLSERVER : DOM\SQL1
Compte d'ouverture de session de SQLSERVERAGENT : DOM\SQLAGT1
Compte proxy de SQLSERVERAGENT : DOM\SQLPROXY1
Tous Admins du domaine
SERVER2 : 2000SRV AS 2ème Controleur de domaine
SQL2000ENT SP2
Compte d'ouverture de session de MSSQLSERVER : DOM\SQL2
Compte d'ouverture de session de SQLSERVERAGENT : DOM\SQLAGT2
Compte proxy de SQLSERVERAGENT : DOM\SQLPROXY2
Tous Admins du domaine
3) Comment je teste ?
1 - Je crée une base TEST sur SERVER2
2 - Je crée une procédure TEST..SP_TESTUSER qui déclenche une erreur de
gravité 16, erreur qui me dit quel utilisateur a exécuté cette SP:
USE TEST
CREATE PROCEDURE [DBO].[SP_TESTUSER] AS
DECLARE @UTIL AS NVARCHAR(256)
SELECT @UTIL = SUSER_SNAME()
SELECT @UTIL = 'CONTEXTE DE SÉCURITÉ : ' + @UTIL
RAISERROR (@UTIL, 16, 1) WITH LOG
GO
3 - Je créer une alerte sur SERVER2 pour un niveau de gravité 16 qui me
prévient par mail.
4 - Je crée un travail sur SERVER2 contenant une étape AX qui exécute
test..SP_TESTUSER :
On Error Resume Next
Connstring = "Driver={Sql
Server};Server=server2;Trusted_Connection=yes;Database=TEST" Set Conn =
CreateObject("Adodb.Connection") Set rs = CreateObject("ADODB.
Recordset") Conn.Open Connstring
conn.execute "EXEC SP_TESTUSER"
Set rs = nothing
Set Conn = nothing
Résultats du test :
-----------------------
* Si le travail appartient à un sysadmin, alors la procédure
SP_TESTUSER est exécutée par DOM\SQLAGT2. (Tout à fait normal)
* Si le travail appartient à un non sysadmin, alors la procédure
SP_TESTUSER est exécutée par DOM\SQLPROXY1. (Tout à fait Anormal : ca
aurait dû être DOM\SQLPROXY2 )
Deuxième Test : Ayant des petits problèmes AD sur SERVER2 :
(
Type de l'événement : Avertissement
Source de l'événement : NTDS Replication
Catégorie de l'événement : Réplication
ID de l'événement : 1586
Date : 07/05/2002
Heure : 09:01:02
Utilisateur : Tout le monde
Ordinateur : SERVER2
Description :
Le point de vérification avec le contrôleur principal de domaine a
échoué. Le processus de vérification sera retenté dans quatre heures.
Une synchronisation complète de la base de données de sécurité vers les
contrôleurs de domaine de bas niveau peut avoir lieu si cet ordinateur
est promu contrôleur principal de domaine avant le prochain point de
vérification correct. L'erreur renvoyée est : Le serveur RPC n'est pas
disponible. )
J'ai alors rétrogradé SERVER2 à un simple serveur membre. Là, aucun
problème, c-a-d Si le travail appartient à un non sysadmin, alors la
procédure SP_TESTUSER est exécutée par DOM\SQLPROXY2.
Troisième Test : Réinstall de AD sur SERVER2 (dcpromo)
Je retombe dans le cas du premier test. C'est DOM/SQLPROXY1 qui execute.
Alors je me dis que c'est peut être normal, non?
Infos complémentaires pour Bruno : tests dans l'ordre indiqué :
1- MSSQL sur SERVER1 démarré. J'arrive à définir d'autres comptes proxy
pour SERVER2. Je vérifie avec EXEC master.dbo.xp_sqlagent_proxy_account
N'GET'. Pourtant c'est tjs DOM\SQLPROXY1 qui execute.
2- Si j'arrete SERVER1, J'ai un peu plus de mal à définir d'autres
comptes proxy pour SERVER2. J'ai une erreur assez aléatoire :
'Descripteur non valide ' Même chose avec
xp_sqlagent_proxy_account N'SET' ...
Je vérifie avec EXEC master.dbo.xp_sqlagent_proxy_account N'GET'.
Pourtant c'est tjs DOM\SQLPROXY1 qui execute.
3- J'arrete MSSQL sur SERVER2 et je redemarre, SERVER1 tjs arrété.
Je vérifie avec EXEC master.dbo.xp_sqlagent_proxy_account N'GET'.
Pourtant c'est tjs DOM\SQLPROXY1 qui execute.
J'ai toujours cette erreur :
Type de l'événement : Avertissement
Source de l'événement : NTDS Replication
Catégorie de l'événement : Réplication
ID de l'événement : 1586
Date : 07/05/2002
Heure : 15:19:44
Utilisateur : Tout le monde
Ordinateur : SERVER2
Description :
Le point de vérification avec le contrôleur principal de domaine a
échoué. Le processus de vérification sera retenté dans quatre heures.
Une synchronisation complète de la base de données de sécurité vers les
contrôleurs de domaine de bas niveau peut avoir lieu si cet ordinateur
est promu contrôleur principal de domaine avant le prochain point de
vérification correct. L'erreur renvoyée est : Le contexte de nommage
est prêt à être supprimé ou bien n'est pas dupliqué à partir du serveur
spécifié.
PS : Sur SERVER1 (CD Principal), Tous les tests depuis le début ont
fonctionné comme attendu.
Bonne lecture. Cyril.