Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Définition compte proxy !?

0 views
Skip to first unread message

Cyril RAYSSIGUIER

unread,
May 6, 2002, 5:29:14 AM5/6/02
to
Bonjour,

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

bruno reiter [MVP]

unread,
May 6, 2002, 6:25:09 AM5/6/02
to
regardes avec ça:
EXEC master.dbo.xp_sqlagent_proxy_account N'GET'

br

"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message
news:Usenet.rnpofhpa@localhost...

Cyril RAYSSIGUIER

unread,
May 6, 2002, 8:29:57 AM5/6/02
to
j'ai bien DOM\U2.
Pourtant, c'est DOM\U1 qui execute l'etape ! Bizarre ...

bruno reiter [MVP]

unread,
May 6, 2002, 9:18:29 AM5/6/02
to
quelle type d'étape (T-SQL, cmdexec...)
qui est propriétaire du travail?

br

"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message

news:Usenet.dhcdqtko@localhost...

power.furax@laposte.net Furax

unread,
May 6, 2002, 9:32:06 AM5/6/02
to
Tiens, un autre MVP... céfilitations Bruno =) !

--
J'ai peut-être raison.... j'ai peut-être tort,
on peut en discuter, sans se mettre à mort !

.oO Le Furax Oo.

Cyril RAYSSIGUIER

unread,
May 6, 2002, 10:19:00 AM5/6/02
to
une étape AX d'un travail appartenant à un non sysadmin défini sur
SERVER2 est éxécutée dans le contexte de sécurité de compte de proxy de
SERVER1 (qui est DOM\U1) !!!!!

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.

bruno reiter [MVP]

unread,
May 6, 2002, 10:39:53 AM5/6/02
to
merci :-)

br

"Furax" <"Furax" power...@laposte.net> wrote in message
news:3cd6...@news.microsoft.com...

Cyril RAYSSIGUIER

unread,
May 7, 2002, 2:07:09 AM5/7/02
to
Et si je change le compte proxy de SERVER1, l'etape du travail sur
SERVER2 s'execute avec le nouveau compte défini sur SERVER1.

a+

bruno reiter [MVP]

unread,
May 7, 2002, 6:40:16 AM5/7/02
to
arrêtes le serveur1 pour voir.

br

"Cyril RAYSSIGUIER" <c.rays...@datasoft.fr> wrote in message

news:Usenet.ieckjbtr@localhost...

Cyril RAYSSIGUIER

unread,
May 7, 2002, 10:36:53 AM5/7/02
to
Retenez votre souffle, je recommence depuis le début. (Ne pas lire si
mal de crane, j'ai testé pour vous.)

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.

0 new messages