J'ai le message suivant sur plusieurs machines, message se repetant 4 fois
(??), j'ai fais plein de recherches sur le net mais je n'arrive pas a trouver
de solution. J'ai sorti les machines du domaine et rerentrer, changer leur
noms, leur adresse, rien y fait !!
Quelqu'un peut-il m'aider SVP?
Les PCs sont en Win XP SP3 ou SP2
Le serveur en Win 2003
Merci.
Type de l'événement : Audit des échecs
Source de l'événement : Security
Catégorie de l'événement : Accès Active Directory
ID de l'événement : 566
Date : 17/12/2008
Heure : 15:52:03
Utilisateur : nomdomaine\PCLIM003$
Ordinateur : nom DC
Description :
Opération d'objet :
Serveur d'objet : DS
Type d'opération : Object Access
Type d'objet : computer
Nom d'objet : CN=PCLIM003,CN=Computers,DC=nomdomaine,DC=com
ID de handle : -
Nom d'utilisateur principal : nom DC$
Domaine principal : nom domaine
ID d'ouv de session principale : (0x0,0x3E7)
Nom d'utilisateur client : PCLIM003$
Domaine client : nom domaine
ID d'ouv de session client : (0x0,0x19DF727C)
Accès : Propriété d'écriture
Propriétés :
---
Public Information
servicePrincipalName
computer
C'était la conclusion à laquelle je voulais parvenir et tu l'énonce de fort belle manière ;) De nos jours, "on" a tendance à directement regarder du côté DNS/réplication dès qu'un problème AD se pose... Sans prendre le temps de lire le log correctement et décomposer le problème.
btw, je me demande si le reverse lookup effectué sous l'implémentation MIT n'est pas "simplement" la conséquence de l'option d'anti ip-spoofing UNIX. Dans le même sense, l'option de "loopbackcheck" implémenté dans LSA à partir du SP1 de 2003 me semble fonctionner de la même manière.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Emmanuel Dreux" wrote in message news:
Bonsoir,
oui tout à fait, un failure audit est généré par la fonction AccessCheck (ses dérivées AccessCheckAndAuditAlarm etc.). Le token de l'appli qui se présente est vérifié par SRM (Security Reference Monitor) auprès des ACL de l'objet qui doit être accédé (c'est la fonction AccessCheck qui réalise l'appel à SRM) et un failure audit est logué en cas d'access denied.
C'est un mécanisme générique de contrôle d'accès aux objets valable quelle que soit l'appli. (Vous pouvez vous même intégrer un accesscheck dans vos appli et générer ces évênements d'audit). Point de DNS, point de salut, ... mais point de failure audit non plus :-)
Par contre c'est vrai que le DNS entre en jeu dans la construction des SPN (appel aux fonction dscrackname, desgetdcname etc., vérification si le hostname est un alias ou un cname etc...), l'implémentation du MIT va même faire un reverselookup.
En cas de pb, ça loguera son jeu d'erreur... mais pas un failure audit.
OK mais cela ne va pas générer un audit failure je pense, plutôt une erreur de style "server unavailable/unreachable"...
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"GG" wrote in message news: > Bonjour, > >> La dessus, je suis d'accord. Je voudrais juste comprendre le lien >> entre le problème de l'écriture d'un SPN et le réplication/DNS. > > Fais l'essai d'ecrire dans un SPN quand un serveur DNS de cet > AD est a la rue (simplement le serveur DNS de AD arrêté) et > tu verras que tu as quelques soucis, si la demande vient du machine > pas du DC lui-même, si essaie d'ecrire dans le SPN a partir du > DC cela fonctionne, me semble-t-il du moins sur un SBS, alors > que d'un serveur répliquant AD de SBS, ce n'est pas la peine. > Je n'ai pas testé sur une plateforme standard (pas SBS) :) > > -- > Cordialement. > GG. > http://forums.sbsfr.org/ > un livre sur SBS http://livresbs.sbsfr.org/ >
Bonjour,
C'était la conclusion à laquelle je voulais parvenir et tu l'énonce de fort
belle manière ;)
De nos jours, "on" a tendance à directement regarder du côté DNS/réplication
dès qu'un problème AD se pose... Sans prendre le temps de lire le log
correctement et décomposer le problème.
btw, je me demande si le reverse lookup effectué sous l'implémentation MIT
n'est pas "simplement" la conséquence de l'option d'anti ip-spoofing UNIX.
Dans le même sense, l'option de "loopbackcheck" implémenté dans LSA à partir
du SP1 de 2003 me semble fonctionner de la même manière.
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Emmanuel Dreux" <EmmanuelDreux@discussions.microsoft.com> wrote in message
news:621920B9-6666-4A12-B779-6B448B81FEF7@microsoft.com...
Bonsoir,
oui tout à fait, un failure audit est généré par la fonction AccessCheck
(ses dérivées
AccessCheckAndAuditAlarm etc.).
Le token de l'appli qui se présente est vérifié par SRM (Security
Reference
Monitor) auprès des ACL de l'objet qui doit être accédé (c'est la fonction
AccessCheck qui réalise l'appel à SRM) et un failure audit est logué en
cas
d'access denied.
C'est un mécanisme générique de contrôle d'accès aux objets valable quelle
que soit l'appli. (Vous pouvez vous même intégrer un accesscheck dans vos
appli et générer ces évênements d'audit).
Point de DNS, point de salut, ... mais point de failure audit non plus :-)
Par contre c'est vrai que le DNS entre en jeu dans la construction des SPN
(appel aux fonction dscrackname, desgetdcname etc., vérification si le
hostname est un alias ou un cname etc...), l'implémentation du MIT va même
faire un reverselookup.
En cas de pb, ça loguera son jeu d'erreur... mais pas un failure audit.
OK mais cela ne va pas générer un audit failure je pense, plutôt une
erreur
de style "server unavailable/unreachable"...
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"GG" <news@nospam.assysm.com> wrote in message
news:eZRhnHUYJHA.1528@TK2MSFTNGP03.phx.gbl...
> Bonjour,
>
>> La dessus, je suis d'accord. Je voudrais juste comprendre le lien
>> entre le problème de l'écriture d'un SPN et le réplication/DNS.
>
> Fais l'essai d'ecrire dans un SPN quand un serveur DNS de cet
> AD est a la rue (simplement le serveur DNS de AD arrêté) et
> tu verras que tu as quelques soucis, si la demande vient du machine
> pas du DC lui-même, si essaie d'ecrire dans le SPN a partir du
> DC cela fonctionne, me semble-t-il du moins sur un SBS, alors
> que d'un serveur répliquant AD de SBS, ce n'est pas la peine.
> Je n'ai pas testé sur une plateforme standard (pas SBS) :)
>
> --
> Cordialement.
> GG.
> http://forums.sbsfr.org/
> un livre sur SBS http://livresbs.sbsfr.org/
>
C'était la conclusion à laquelle je voulais parvenir et tu l'énonce de fort belle manière ;) De nos jours, "on" a tendance à directement regarder du côté DNS/réplication dès qu'un problème AD se pose... Sans prendre le temps de lire le log correctement et décomposer le problème.
btw, je me demande si le reverse lookup effectué sous l'implémentation MIT n'est pas "simplement" la conséquence de l'option d'anti ip-spoofing UNIX. Dans le même sense, l'option de "loopbackcheck" implémenté dans LSA à partir du SP1 de 2003 me semble fonctionner de la même manière.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Emmanuel Dreux" wrote in message news:
Bonsoir,
oui tout à fait, un failure audit est généré par la fonction AccessCheck (ses dérivées AccessCheckAndAuditAlarm etc.). Le token de l'appli qui se présente est vérifié par SRM (Security Reference Monitor) auprès des ACL de l'objet qui doit être accédé (c'est la fonction AccessCheck qui réalise l'appel à SRM) et un failure audit est logué en cas d'access denied.
C'est un mécanisme générique de contrôle d'accès aux objets valable quelle que soit l'appli. (Vous pouvez vous même intégrer un accesscheck dans vos appli et générer ces évênements d'audit). Point de DNS, point de salut, ... mais point de failure audit non plus :-)
Par contre c'est vrai que le DNS entre en jeu dans la construction des SPN (appel aux fonction dscrackname, desgetdcname etc., vérification si le hostname est un alias ou un cname etc...), l'implémentation du MIT va même faire un reverselookup.
En cas de pb, ça loguera son jeu d'erreur... mais pas un failure audit.
OK mais cela ne va pas générer un audit failure je pense, plutôt une erreur de style "server unavailable/unreachable"...
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"GG" wrote in message news: > Bonjour, > >> La dessus, je suis d'accord. Je voudrais juste comprendre le lien >> entre le problème de l'écriture d'un SPN et le réplication/DNS. > > Fais l'essai d'ecrire dans un SPN quand un serveur DNS de cet > AD est a la rue (simplement le serveur DNS de AD arrêté) et > tu verras que tu as quelques soucis, si la demande vient du machine > pas du DC lui-même, si essaie d'ecrire dans le SPN a partir du > DC cela fonctionne, me semble-t-il du moins sur un SBS, alors > que d'un serveur répliquant AD de SBS, ce n'est pas la peine. > Je n'ai pas testé sur une plateforme standard (pas SBS) :) > > -- > Cordialement. > GG. > http://forums.sbsfr.org/ > un livre sur SBS http://livresbs.sbsfr.org/ >
