Salut !
Je repose ma question car je suis sûr qu'il y a quelqu'un dans ce forum qui
a la réponse.
J'ai programmé un service et un client.
Le service démarre avec le compte SYSTEM.
Le client démarre avec le compte utilisateur (enfin je crois, c'est un exe
tout ce qu'il y a de plus classique)
Ce service écoute par un socket les clients.
Il est prévu que le client puisse demander au service d'écrire dans
l'ActiveDirectory, et c'est
cette fonctionalité qui ne marche pas correctement :
Quand le client est lancé par un admin, pas de problème.
Quand le client est lancé par un utilisateur du domaine le service génère
une exception
qui dit qu'il ne peut pas écrire dans l'ActiveDirectory à cause d'un
problème de droit.
Ce que je ne comprend pas, c'est que c'est le service qui écrit dans
l'ActiveDirectory, donc le compte
SYSTEM, quelque soit l'utilisateur qui utilise le client.
Alors pourquoi ca fonctionne quand le client est lancé par un admin et pas
quand il est lancé par un utilisateur du domaine ??? (c'est un truc de fous
ça non ?!?)
Merci pour votre coup de pouce !
Au cas où, voici l'exception :
System.UnauthorizedAccessException: Erreur d'accès général refusé
at System.DirectoryServices.Interop.IAds.SetInfo()
at System.DirectoryServices.DirectoryEntry.CommitChanges()
at SocketAsyncServerLib.LDAPClass.SetTel(String User, String Tel)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Simon Mourier [MS]
A la différence des named pipes (et encore faut il faire de l'impersonation), les sockets ne transmettent pas l'identité (sauf à le programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour wininet/IE), donc, d'après votre description, ça ne semble pas possible. Pouvez vous vérifier ce que vous dites? Essayez d'afficher l'identité de l'utilisateur lors du SetInfo (WindowsIdentity.GetCurrent().Name) dans le service. Avez vous programmé vous-même le service de socket?
Simon.
"MrChris" a écrit dans le message de news: %23UxWj$
Salut ! Je repose ma question car je suis sûr qu'il y a quelqu'un dans ce forum qui a la réponse.
J'ai programmé un service et un client. Le service démarre avec le compte SYSTEM. Le client démarre avec le compte utilisateur (enfin je crois, c'est un exe tout ce qu'il y a de plus classique) Ce service écoute par un socket les clients. Il est prévu que le client puisse demander au service d'écrire dans l'ActiveDirectory, et c'est cette fonctionalité qui ne marche pas correctement :
Quand le client est lancé par un admin, pas de problème. Quand le client est lancé par un utilisateur du domaine le service génère une exception qui dit qu'il ne peut pas écrire dans l'ActiveDirectory à cause d'un problème de droit.
Ce que je ne comprend pas, c'est que c'est le service qui écrit dans l'ActiveDirectory, donc le compte SYSTEM, quelque soit l'utilisateur qui utilise le client.
Alors pourquoi ca fonctionne quand le client est lancé par un admin et pas quand il est lancé par un utilisateur du domaine ??? (c'est un truc de fous ça non ?!?)
Merci pour votre coup de pouce !
Au cas où, voici l'exception : System.UnauthorizedAccessException: Erreur d'accès général refusé at System.DirectoryServices.Interop.IAds.SetInfo() at System.DirectoryServices.DirectoryEntry.CommitChanges() at SocketAsyncServerLib.LDAPClass.SetTel(String User, String Tel)
MrChris
A la différence des named pipes (et encore faut il faire de
l'impersonation), les sockets ne transmettent pas l'identité (sauf à le
programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour
wininet/IE), donc, d'après votre description, ça ne semble pas possible.
Pouvez vous vérifier ce que vous dites? Essayez d'afficher l'identité de
l'utilisateur lors du SetInfo (WindowsIdentity.GetCurrent().Name) dans le
service. Avez vous programmé vous-même le service de socket?
Simon.
"MrChris" <mrchris@spam.com> a écrit dans le message de news:
%23UxWj$BGFHA.1456@TK2MSFTNGP09.phx.gbl...
Salut !
Je repose ma question car je suis sûr qu'il y a quelqu'un dans ce forum
qui a la réponse.
J'ai programmé un service et un client.
Le service démarre avec le compte SYSTEM.
Le client démarre avec le compte utilisateur (enfin je crois, c'est un exe
tout ce qu'il y a de plus classique)
Ce service écoute par un socket les clients.
Il est prévu que le client puisse demander au service d'écrire dans
l'ActiveDirectory, et c'est
cette fonctionalité qui ne marche pas correctement :
Quand le client est lancé par un admin, pas de problème.
Quand le client est lancé par un utilisateur du domaine le service génère
une exception
qui dit qu'il ne peut pas écrire dans l'ActiveDirectory à cause d'un
problème de droit.
Ce que je ne comprend pas, c'est que c'est le service qui écrit dans
l'ActiveDirectory, donc le compte
SYSTEM, quelque soit l'utilisateur qui utilise le client.
Alors pourquoi ca fonctionne quand le client est lancé par un admin et pas
quand il est lancé par un utilisateur du domaine ??? (c'est un truc de
fous ça non ?!?)
Merci pour votre coup de pouce !
Au cas où, voici l'exception :
System.UnauthorizedAccessException: Erreur d'accès général refusé
at System.DirectoryServices.Interop.IAds.SetInfo()
at System.DirectoryServices.DirectoryEntry.CommitChanges()
at SocketAsyncServerLib.LDAPClass.SetTel(String User, String Tel)
A la différence des named pipes (et encore faut il faire de l'impersonation), les sockets ne transmettent pas l'identité (sauf à le programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour wininet/IE), donc, d'après votre description, ça ne semble pas possible. Pouvez vous vérifier ce que vous dites? Essayez d'afficher l'identité de l'utilisateur lors du SetInfo (WindowsIdentity.GetCurrent().Name) dans le service. Avez vous programmé vous-même le service de socket?
Simon.
"MrChris" a écrit dans le message de news: %23UxWj$
Salut ! Je repose ma question car je suis sûr qu'il y a quelqu'un dans ce forum qui a la réponse.
J'ai programmé un service et un client. Le service démarre avec le compte SYSTEM. Le client démarre avec le compte utilisateur (enfin je crois, c'est un exe tout ce qu'il y a de plus classique) Ce service écoute par un socket les clients. Il est prévu que le client puisse demander au service d'écrire dans l'ActiveDirectory, et c'est cette fonctionalité qui ne marche pas correctement :
Quand le client est lancé par un admin, pas de problème. Quand le client est lancé par un utilisateur du domaine le service génère une exception qui dit qu'il ne peut pas écrire dans l'ActiveDirectory à cause d'un problème de droit.
Ce que je ne comprend pas, c'est que c'est le service qui écrit dans l'ActiveDirectory, donc le compte SYSTEM, quelque soit l'utilisateur qui utilise le client.
Alors pourquoi ca fonctionne quand le client est lancé par un admin et pas quand il est lancé par un utilisateur du domaine ??? (c'est un truc de fous ça non ?!?)
Merci pour votre coup de pouce !
Au cas où, voici l'exception : System.UnauthorizedAccessException: Erreur d'accès général refusé at System.DirectoryServices.Interop.IAds.SetInfo() at System.DirectoryServices.DirectoryEntry.CommitChanges() at SocketAsyncServerLib.LDAPClass.SetTel(String User, String Tel)
MrChris
MrChris
>A la différence des named pipes (et encore faut il faire de l'impersonation), les sockets ne transmettent pas l'identité (sauf à le programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour wininet/IE), donc, d'après votre description, ça ne semble pas possible.
Pourtant c'est ce qui se passe. Mais je ne sais pas si c'est du à la différance de user qui lance l'appli.
Pouvez vous vérifier ce que vous dites ?
Depuis une semaine j'essaye dans tout les sens !!! Je pense que c'est vérifié !!! Mais ce n'est seulement que ce que je constate, maintenant je ne peut pas affirmer que l'utilisateur du client influe sur le service !
Essayez d'afficher l'identité de l'utilisateur lors du SetInfo (WindowsIdentity.GetCurrent().Name) dans le service.
Très bonne idée !!! J'avais déja essayé un truc du style environment.username
Avez vous programmé vous-même le service de socket?
Oui, et en asynchrone et je sais que je n'ai pas fait d'impersonation.
Merci pour ton post !!! Je répond dès que j'ai les résultats avec WindowsIdentity.GetCurrent().Name !
Merci encore ! @+MrChris
>A la différence des named pipes (et encore faut il faire de
l'impersonation), les sockets ne transmettent pas l'identité (sauf à le
programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour
wininet/IE), donc, d'après votre description, ça ne semble pas possible.
Pourtant c'est ce qui se passe. Mais je ne sais pas si c'est du à la
différance
de user qui lance l'appli.
Pouvez vous vérifier ce que vous dites ?
Depuis une semaine j'essaye dans tout les sens !!!
Je pense que c'est vérifié !!!
Mais ce n'est seulement que ce que je constate, maintenant
je ne peut pas affirmer que l'utilisateur du client influe sur le service !
Essayez d'afficher l'identité de l'utilisateur lors du SetInfo
(WindowsIdentity.GetCurrent().Name) dans le service.
Très bonne idée !!!
J'avais déja essayé un truc du style environment.username
Avez vous programmé vous-même le service de socket?
Oui, et en asynchrone et je sais que je n'ai pas fait d'impersonation.
Merci pour ton post !!!
Je répond dès que j'ai les résultats avec WindowsIdentity.GetCurrent().Name
!
>A la différence des named pipes (et encore faut il faire de l'impersonation), les sockets ne transmettent pas l'identité (sauf à le programmer explicitement avec SSPI par exemple, comme NTLM sur HTTP pour wininet/IE), donc, d'après votre description, ça ne semble pas possible.
Pourtant c'est ce qui se passe. Mais je ne sais pas si c'est du à la différance de user qui lance l'appli.
Pouvez vous vérifier ce que vous dites ?
Depuis une semaine j'essaye dans tout les sens !!! Je pense que c'est vérifié !!! Mais ce n'est seulement que ce que je constate, maintenant je ne peut pas affirmer que l'utilisateur du client influe sur le service !
Essayez d'afficher l'identité de l'utilisateur lors du SetInfo (WindowsIdentity.GetCurrent().Name) dans le service.
Très bonne idée !!! J'avais déja essayé un truc du style environment.username
Avez vous programmé vous-même le service de socket?
Oui, et en asynchrone et je sais que je n'ai pas fait d'impersonation.
Merci pour ton post !!! Je répond dès que j'ai les résultats avec WindowsIdentity.GetCurrent().Name !
Merci encore ! @+MrChris
MrChris
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois. Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD... Je ne comprend pas comment cela pouvait fonctionner avant ! Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
Merci MrChris
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois.
Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD...
Je ne comprend pas comment cela pouvait fonctionner avant !
Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois. Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD... Je ne comprend pas comment cela pouvait fonctionner avant ! Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
Merci MrChris
Simon Mourier [MS]
ahah... je savais bien que c'était louche :-)
Il faut soit faire tourner le service dans un autre compte, soit utiliser les constructeurs de DirectoryEntry appropriés (avec user/password). SYSTEM c'est le compte local de la machine, il ne peut donc implicitement se connecter à AD.
Simon.
"MrChris" a écrit dans le message de news:
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois. Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD... Je ne comprend pas comment cela pouvait fonctionner avant ! Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
Merci MrChris
ahah... je savais bien que c'était louche :-)
Il faut soit faire tourner le service dans un autre compte, soit utiliser
les constructeurs de DirectoryEntry appropriés (avec user/password). SYSTEM
c'est le compte local de la machine, il ne peut donc implicitement se
connecter à AD.
Simon.
"MrChris" <mrchris@spam.com> a écrit dans le message de news:
uGnhWtYGFHA.3504@TK2MSFTNGP12.phx.gbl...
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois.
Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD...
Je ne comprend pas comment cela pouvait fonctionner avant !
Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
Il faut soit faire tourner le service dans un autre compte, soit utiliser les constructeurs de DirectoryEntry appropriés (avec user/password). SYSTEM c'est le compte local de la machine, il ne peut donc implicitement se connecter à AD.
Simon.
"MrChris" a écrit dans le message de news:
Bon, WindowsIdentity.GetCurrent().Name me sort bien SYSTEM à chaque fois. Et quelque soit l'utilisateur, je ne peut pas écrire dans l'AD... Je ne comprend pas comment cela pouvait fonctionner avant ! Mais au moins c'est un comportement qui me semble plus normal !
Comment faire pour autoriser le compte SYSTEM à écrire dans l'AD ???
