Quel champ utlilisé pour identifier de façon unique un objet AD?
3 réponses
Fred
Bonjour à tous,
Je suis en train de développer un intranet en ASP qui se connecte à
notre AD (2003 R2) pour les identifications.
Au niveau identification, le principe est le suivant :
- L'utilisateur se logue sur IIS avec son compte
- Il accède à une arborescence dont les droits sont définis en fonction
des groupes AD.
Je lie donc les rubriques à un ou plusieurs groupes AD autorisés à
accéder à cette rubrique.
Au départ, je comptais utiliser le chemin complet du groupe, mais si je
déplace un groupe dans un autre OU ou le renomme, ça ne fonctionnera plus.
Quel est le meilleur champ à utiliser qui ne change pas si je déplace ou
renomme un groupe ?
Vaut-il mieux utiliser objectGUID ou objectSid ?
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
Lognoul Marc [MVP]
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Fred" wrote in message news:
Bonjour à tous,
Je suis en train de développer un intranet en ASP qui se connecte à notre AD (2003 R2) pour les identifications.
Au niveau identification, le principe est le suivant : - L'utilisateur se logue sur IIS avec son compte - Il accède à une arborescence dont les droits sont définis en fonction des groupes AD.
Je lie donc les rubriques à un ou plusieurs groupes AD autorisés à accéder à cette rubrique.
Au départ, je comptais utiliser le chemin complet du groupe, mais si je déplace un groupe dans un autre OU ou le renomme, ça ne fonctionnera plus.
Quel est le meilleur champ à utiliser qui ne change pas si je déplace ou renomme un groupe ? Vaut-il mieux utiliser objectGUID ou objectSid ?
Merci pour votre aide,
@+
Fred
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous
rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe
puisse, sous certaines conditions, en posséder plusieurs (SID History), le
GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de
votre application est basée sur les groupes Windows et donc, d'une certaine
manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent
nativement.
Dans les deux cas, Windows fournit des API de traduction d'un format de nom
vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil
sur AzMan, un composant Windows qui vous permettra de gagner du temps dans
le développement tout en vous basant sur la sécurité Windows/AD:
http://www.techheadbrothers.com/Articles.aspx/securite-azman
http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Fred" <fred_nospam_@plansdereseaux.com> wrote in message
news:ut2zi7CiJHA.5732@TK2MSFTNGP05.phx.gbl...
Bonjour à tous,
Je suis en train de développer un intranet en ASP qui se connecte à notre
AD (2003 R2) pour les identifications.
Au niveau identification, le principe est le suivant :
- L'utilisateur se logue sur IIS avec son compte
- Il accède à une arborescence dont les droits sont définis en fonction
des groupes AD.
Je lie donc les rubriques à un ou plusieurs groupes AD autorisés à accéder
à cette rubrique.
Au départ, je comptais utiliser le chemin complet du groupe, mais si je
déplace un groupe dans un autre OU ou le renomme, ça ne fonctionnera plus.
Quel est le meilleur champ à utiliser qui ne change pas si je déplace ou
renomme un groupe ?
Vaut-il mieux utiliser objectGUID ou objectSid ?
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Fred" wrote in message news:
Bonjour à tous,
Je suis en train de développer un intranet en ASP qui se connecte à notre AD (2003 R2) pour les identifications.
Au niveau identification, le principe est le suivant : - L'utilisateur se logue sur IIS avec son compte - Il accède à une arborescence dont les droits sont définis en fonction des groupes AD.
Je lie donc les rubriques à un ou plusieurs groupes AD autorisés à accéder à cette rubrique.
Au départ, je comptais utiliser le chemin complet du groupe, mais si je déplace un groupe dans un autre OU ou le renomme, ça ne fonctionnera plus.
Quel est le meilleur champ à utiliser qui ne change pas si je déplace ou renomme un groupe ? Vaut-il mieux utiliser objectGUID ou objectSid ?
Merci pour votre aide,
@+
Fred
Fred
Lognoul Marc [MVP] a écrit :
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos. AzMan a l'air intéressant mais un peu disproportionné par rapport à mes besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _ ("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local") wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû à une notation qui n'est pas la même dans les 2 cas (string / octet string).
@+
Fred
Lognoul Marc [MVP] a écrit :
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que
vous rencontriez des problèmes liés au fait qu'une utilisateur ou un
groupe puisse, sous certaines conditions, en posséder plusieurs (SID
History), le GUID n'est pas affecté par ce problème. D'un autre côté, si
la sécurité de votre application est basée sur les groupes Windows et
donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les
SIDs y sont présent nativement.
Dans les deux cas, Windows fournit des API de traduction d'un format de
nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un
œil sur AzMan, un composant Windows qui vous permettra de gagner du
temps dans le développement tout en vous basant sur la sécurité Windows/AD:
http://www.techheadbrothers.com/Articles.aspx/securite-azman
http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos.
AzMan a l'air intéressant mais un peu disproportionné par rapport à mes
besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _
("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local")
wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que
l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû
à une notation qui n'est pas la même dans les 2 cas (string / octet string).
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos. AzMan a l'air intéressant mais un peu disproportionné par rapport à mes besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _ ("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local") wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû à une notation qui n'est pas la même dans les 2 cas (string / octet string).
@+
Fred
Lognoul Marc [MVP]
Voici une exemple de conversion en VBS: http://support.microsoft.com/kb/325648/fr
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Fred" wrote in message news:
Lognoul Marc [MVP] a écrit :
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos. AzMan a l'air intéressant mais un peu disproportionné par rapport à mes besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _ ("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local") wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû à une notation qui n'est pas la même dans les 2 cas (string / octet string).
@+
Fred
Voici une exemple de conversion en VBS:
http://support.microsoft.com/kb/325648/fr
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Fred" <fred_nospam_@plansdereseaux.com> wrote in message
news:u2bKqcDiJHA.5000@TK2MSFTNGP04.phx.gbl...
Lognoul Marc [MVP] a écrit :
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous
rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe
puisse, sous certaines conditions, en posséder plusieurs (SID History),
le GUID n'est pas affecté par ce problème. D'un autre côté, si la
sécurité de votre application est basée sur les groupes Windows et donc,
d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y
sont présent nativement.
Dans les deux cas, Windows fournit des API de traduction d'un format de
nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un
œil sur AzMan, un composant Windows qui vous permettra de gagner du temps
dans le développement tout en vous basant sur la sécurité Windows/AD:
http://www.techheadbrothers.com/Articles.aspx/securite-azman
http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos.
AzMan a l'air intéressant mais un peu disproportionné par rapport à mes
besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _
("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local")
wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que
l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû à
une notation qui n'est pas la même dans les 2 cas (string / octet string).
Voici une exemple de conversion en VBS: http://support.microsoft.com/kb/325648/fr
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Fred" wrote in message news:
Lognoul Marc [MVP] a écrit :
Bonjour,
Bien que le SID soit une bonne option de départ, il est possible que vous rencontriez des problèmes liés au fait qu'une utilisateur ou un groupe puisse, sous certaines conditions, en posséder plusieurs (SID History), le GUID n'est pas affecté par ce problème. D'un autre côté, si la sécurité de votre application est basée sur les groupes Windows et donc, d'une certaine manière par le jeton d'accès de l'utilisateur, les SIDs y sont présent nativement. Dans les deux cas, Windows fournit des API de traduction d'un format de nom vers un autre, avec évidemment des limites dans certains cas.
Si l'architecture de votre application n'est pas encore arrêté, jetez un œil sur AzMan, un composant Windows qui vous permettra de gagner du temps dans le développement tout en vous basant sur la sécurité Windows/AD: http://www.techheadbrothers.com/Articles.aspx/securite-azman http://msdn.microsoft.com/en-us/magazine/cc300469.aspx
Merci pour ces infos. AzMan a l'air intéressant mais un peu disproportionné par rapport à mes besoin.
Par contre, en utilisant le GUID, j'ai trouvé ce qu'il me fallait :
Pour le récupérer :
Set objGroup = GetObject _ ("GC://CN=le groupe,OU=mon ou,DC=domain,DC=local") wscript.echo objGroup.GUID
Par contre, la proporiété GUID ne retourne pas la même valeur que l'objectGUID dans ADExplorer, par ex, mais il semblerait que ce soit dû à une notation qui n'est pas la même dans les 2 cas (string / octet string).
