je suis en train (d'essayer) d'effectuer une migration d'un réseau NT4
vers 2003. Nouveau serveur, nouveau domaine.
J'ai réussi à installer et configurer ADMT pour migrer les comptes et
leurs mot de passe.
J'ai migré mon compte en prenant soin de migrer l'historique SID pour
garder les permissions.
J'ai basculé mon pc dans le nouveau domaine.
Problème 1:
Quand je me connecte sur le nouveau domaine, je n'ai plus les
permissions d'accés au serveur de fichiers (déjà sous 2003) membre de
l'ancien domaine.
J'ai pourtant bien une approbation bidirectionnelle entre les deux
domaines.
Pourquoi ? comment récupérer mes droits ?
Problème 2:
J'ai utilisé ADMT pour migrer mon pc. mais j'ai du ajouter le groupe
"admins du domaine" de l'AD dans le groupe administrateur local, sans
quoi j'avais une erreur d'accés.
pourtant le groupe "Admins du domaine" de l'AD est bien dans le groupe
"Administrateurs" de NT4 et réciproquement.
J'ai comme l'impression que l'approbation ne fonnctionne pas
correctement. Pourtant je n'ai pas de problème pour la migration des
comptes...
Quelqu'un aurait-il une explication ?
Je dois migrer pas mal de stations, alors tous les retours d'expérience
sont les bienvenus.
re Patrice, désolé pour le retard, je n'ai pas vu la question avant ce matin :s
oui. J'ai fait pas mal de manips depuis et maintenant ça marche!
bien :)
L'embettant c'est que j'ignore toujours l'origine du problème d'avant.
la migration de l'historique Sid dans un premier temps à mon avis
en fait ça marche même sans translater la sécurité. Si je partage une ressource avec des permissions sur mon ancien compte, j'y accède aussi bien de mon ancien compte que du nouveau. En revanche si je mets les permissions sur mon nouveau compte, je n'y accède pas depuis l'ancien.
C'est le but :
après migration de l'historique Sid, le nouveau compte dispose aussi du Sid de l'ancien. Donc les permissions attribués à l'anciens sont accessibles : - à l'ancien - au nouveau qui conserve aussi le Sid de l'ancien
si je translate la sécurité, les permissions de l'ancien domaine sont remplacées par celles du nouveau, et de ce fait je n'y est plus accès depuis mon ancien compte.
normal, si tu attribue des permissions sur le nouveau, seul le Sid du nouveau peut y accéder (on ne placera pas le Sid de l'ancien conservé par le nouveau compte, mais bien le vrai Sid de celui-ci)
J'ai réalisé la manip plusieurs fois et il n'y a aucun doute.
Tu avais pourtant dis qu'après la translation je devais toujours y accéder depuis mon ancien compte. alors où est le problème ?
Ça n'est pas un problème, juste une erreur de compréhension commune ^_^ j'étais resté à tes premières questions type : > Et si jamais j'oublie de migrer un compte ou un groupe avant de migrer le serveur, que se passe t-il ? ma réponse de l'époque : migre le serveur à la fin, la migration de la machine et la translation de la sécurité sont des actions décorellées. [du fait de l'utilisation de l'historique Sid, le nouveau peut accéder à l'ancien]
> Les utilisateurs encore connectés sur l'ancien domaine auront-ils accès au serveur sur le nouveau domaine sans problème ? ma réponse de l'époque : Non, l'historique Sid ne fonctionne que dans le sens nouveau vers ancien et non l'inverse. bref, passons...
Cela dit, ce n'est pas très gênant, du moment qu'on y accède depuis le compte migré, je peux migrer les comptes avant de toucher à la sécurité.
tout juste, on appellera ça, la phase de cohabitation, ou les nouveaux comptes peuvent accéder aux anciennes ressources [l'inverse ne marchant donc pas]
Autre chose: comment faire pour migrer les groupes tels que "Admins du domaine" dont mon ancien compte fait parti ? Lorsque je tente une migration il dis qu'un groupe du même nom éxiste déjà. Je pensais qu'il aurait recopié le SID du groupe dans l'historique du nouveau mais apparamment c'est pas le cas.
c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci, je te propose d'utiliser l'outil subinacl qui permet de faire des remplacements sur des droits du type : ancien_domaineadmin = nouveau_domadmin. A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes "admins du domaine" et assimilés. à toi de faire ça manuellement ou par script.
-- Jonathan BISMUTH MCSE 2000/ADSI-AutoIT Scripter Transcript (ID: 691839, code: MCSE2000) www.portail-mcse.net pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" a écrit dans le message de news: O%
j'ai essayé tous les objets les uns aprés les autres sans succés. pourtant les droits semblent bien avoir été convertis puisqu'à la place de ANCIENDOMAINEmonlogin j'ai désormais NOUVEAUDOMAINEmonlogin malgrés ça j'ai toujours accès avec mon ancien compte, mais pas avec le nouveau. ça me parait louche...
Pour savoir, les droits ont tous été translatés (partages et sécurité)? Juste comme ça, tente de cocher en simultané : fichiers et dossiers, ressources partagées et droits des utilisateurs
....
re Patrice, désolé pour le retard, je n'ai pas vu la question avant ce matin
:s
oui.
J'ai fait pas mal de manips depuis et maintenant ça marche!
bien :)
L'embettant c'est que j'ignore toujours l'origine du problème d'avant.
la migration de l'historique Sid dans un premier temps à mon avis
en fait ça marche même sans translater la sécurité. Si je partage une
ressource avec des permissions sur mon ancien compte, j'y accède aussi
bien de mon ancien compte que du nouveau. En revanche si je mets les
permissions sur mon nouveau compte, je n'y accède pas depuis l'ancien.
C'est le but :
après migration de l'historique Sid, le nouveau compte dispose aussi du Sid
de l'ancien.
Donc les permissions attribués à l'anciens sont accessibles :
- à l'ancien
- au nouveau qui conserve aussi le Sid de l'ancien
si je translate la sécurité, les permissions de l'ancien domaine sont
remplacées par celles du nouveau, et de ce fait je n'y est plus accès
depuis mon ancien compte.
normal, si tu attribue des permissions sur le nouveau, seul le Sid du
nouveau peut y accéder (on ne placera pas le Sid de l'ancien conservé par
le nouveau compte, mais bien le vrai Sid de celui-ci)
J'ai réalisé la manip plusieurs fois et il n'y a aucun doute.
Tu avais pourtant dis qu'après la translation je devais toujours y accéder
depuis mon ancien compte. alors où est le problème ?
Ça n'est pas un problème, juste une erreur de compréhension commune ^_^
j'étais resté à tes premières questions type :
> Et si jamais j'oublie de migrer un compte ou un groupe avant de migrer
le serveur, que se passe t-il ?
ma réponse de l'époque : migre le serveur à la fin, la migration de la
machine et la translation de
la sécurité sont des actions décorellées. [du fait de l'utilisation de
l'historique Sid, le nouveau peut accéder à l'ancien]
> Les utilisateurs encore connectés sur l'ancien domaine auront-ils
accès au serveur sur le nouveau domaine sans problème ?
ma réponse de l'époque : Non, l'historique Sid ne fonctionne que dans le
sens nouveau vers ancien et non l'inverse.
bref, passons...
Cela dit, ce n'est pas très gênant, du moment qu'on y accède depuis le
compte migré, je peux migrer les comptes avant de toucher à la sécurité.
tout juste, on appellera ça, la phase de cohabitation, ou les nouveaux
comptes peuvent accéder aux anciennes ressources [l'inverse ne marchant donc
pas]
Autre chose: comment faire pour migrer les groupes tels que "Admins du
domaine" dont mon ancien compte fait parti ? Lorsque je tente une
migration il dis qu'un groupe du même nom éxiste déjà. Je pensais qu'il
aurait recopié le SID du groupe dans l'historique du nouveau mais
apparamment c'est pas le cas.
c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc
ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci,
je te propose d'utiliser l'outil subinacl qui permet de faire des
remplacements sur des droits du type : ancien_domaineadmin =
nouveau_domadmin.
A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes
"admins du domaine" et assimilés. à toi de faire ça manuellement ou par
script.
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" <nospam@nospam.com> a écrit dans le message de news:
O%23RNZuRkFHA.1412@TK2MSFTNGP09.phx.gbl...
j'ai essayé tous les objets les uns aprés les autres sans succés.
pourtant les droits semblent bien avoir été convertis puisqu'à la place
de ANCIENDOMAINEmonlogin j'ai désormais NOUVEAUDOMAINEmonlogin
malgrés ça j'ai toujours accès avec mon ancien compte, mais pas avec le
nouveau.
ça me parait louche...
Pour savoir, les droits ont tous été translatés (partages et sécurité)?
Juste comme ça, tente de cocher en simultané : fichiers et dossiers,
ressources partagées et droits des utilisateurs
re Patrice, désolé pour le retard, je n'ai pas vu la question avant ce matin :s
oui. J'ai fait pas mal de manips depuis et maintenant ça marche!
bien :)
L'embettant c'est que j'ignore toujours l'origine du problème d'avant.
la migration de l'historique Sid dans un premier temps à mon avis
en fait ça marche même sans translater la sécurité. Si je partage une ressource avec des permissions sur mon ancien compte, j'y accède aussi bien de mon ancien compte que du nouveau. En revanche si je mets les permissions sur mon nouveau compte, je n'y accède pas depuis l'ancien.
C'est le but :
après migration de l'historique Sid, le nouveau compte dispose aussi du Sid de l'ancien. Donc les permissions attribués à l'anciens sont accessibles : - à l'ancien - au nouveau qui conserve aussi le Sid de l'ancien
si je translate la sécurité, les permissions de l'ancien domaine sont remplacées par celles du nouveau, et de ce fait je n'y est plus accès depuis mon ancien compte.
normal, si tu attribue des permissions sur le nouveau, seul le Sid du nouveau peut y accéder (on ne placera pas le Sid de l'ancien conservé par le nouveau compte, mais bien le vrai Sid de celui-ci)
J'ai réalisé la manip plusieurs fois et il n'y a aucun doute.
Tu avais pourtant dis qu'après la translation je devais toujours y accéder depuis mon ancien compte. alors où est le problème ?
Ça n'est pas un problème, juste une erreur de compréhension commune ^_^ j'étais resté à tes premières questions type : > Et si jamais j'oublie de migrer un compte ou un groupe avant de migrer le serveur, que se passe t-il ? ma réponse de l'époque : migre le serveur à la fin, la migration de la machine et la translation de la sécurité sont des actions décorellées. [du fait de l'utilisation de l'historique Sid, le nouveau peut accéder à l'ancien]
> Les utilisateurs encore connectés sur l'ancien domaine auront-ils accès au serveur sur le nouveau domaine sans problème ? ma réponse de l'époque : Non, l'historique Sid ne fonctionne que dans le sens nouveau vers ancien et non l'inverse. bref, passons...
Cela dit, ce n'est pas très gênant, du moment qu'on y accède depuis le compte migré, je peux migrer les comptes avant de toucher à la sécurité.
tout juste, on appellera ça, la phase de cohabitation, ou les nouveaux comptes peuvent accéder aux anciennes ressources [l'inverse ne marchant donc pas]
Autre chose: comment faire pour migrer les groupes tels que "Admins du domaine" dont mon ancien compte fait parti ? Lorsque je tente une migration il dis qu'un groupe du même nom éxiste déjà. Je pensais qu'il aurait recopié le SID du groupe dans l'historique du nouveau mais apparamment c'est pas le cas.
c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci, je te propose d'utiliser l'outil subinacl qui permet de faire des remplacements sur des droits du type : ancien_domaineadmin = nouveau_domadmin. A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes "admins du domaine" et assimilés. à toi de faire ça manuellement ou par script.
-- Jonathan BISMUTH MCSE 2000/ADSI-AutoIT Scripter Transcript (ID: 691839, code: MCSE2000) www.portail-mcse.net pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" a écrit dans le message de news: O%
j'ai essayé tous les objets les uns aprés les autres sans succés. pourtant les droits semblent bien avoir été convertis puisqu'à la place de ANCIENDOMAINEmonlogin j'ai désormais NOUVEAUDOMAINEmonlogin malgrés ça j'ai toujours accès avec mon ancien compte, mais pas avec le nouveau. ça me parait louche...
Pour savoir, les droits ont tous été translatés (partages et sécurité)? Juste comme ça, tente de cocher en simultané : fichiers et dossiers, ressources partagées et droits des utilisateurs
....
Patriceg
> c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci, je te propose d'utiliser l'outil subinacl qui permet de faire des remplacements sur des droits du type : ancien_domaineadmin = nouveau_domadmin. A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes "admins du domaine" et assimilés. à toi de faire ça manuellement ou par script.
C'est bien pratique cet outil! si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de remplacer au préalable toutes les permissions basées sur ces groupes par d'autres "customs" que je pourrais migrer ensuite. Existerait t-il une commande (ou un script) pour savoir s'il reste des permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
Patrice.
>
c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc
ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci,
je te propose d'utiliser l'outil subinacl qui permet de faire des
remplacements sur des droits du type : ancien_domaineadmin =
nouveau_domadmin.
A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes
"admins du domaine" et assimilés. à toi de faire ça manuellement ou par
script.
C'est bien pratique cet outil!
si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de
remplacer au préalable toutes les permissions basées sur ces groupes par
d'autres "customs" que je pourrais migrer ensuite.
Existerait t-il une commande (ou un script) pour savoir s'il reste des
permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
> c'est un des problèmes d'ADMT, il ne migre pas les groupes prédéfinis, donc ni "admins du domaine", ni "administrateurs", "utilisateurs"..., pour ceci, je te propose d'utiliser l'outil subinacl qui permet de faire des remplacements sur des droits du type : ancien_domaineadmin = nouveau_domadmin. A noter qu'il n'y aura dans tous les cas, pas d'ajout de membres au groupes "admins du domaine" et assimilés. à toi de faire ça manuellement ou par script.
C'est bien pratique cet outil! si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de remplacer au préalable toutes les permissions basées sur ces groupes par d'autres "customs" que je pourrais migrer ensuite. Existerait t-il une commande (ou un script) pour savoir s'il reste des permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
Patrice.
Jonathan Bismuth
c'est même l'outil essentiel, tu n'as pas idée :) Un certain nombre d'admins et consultants l'utilisent exactement pour ce que tu veux faire afin de remplacer un groupe builtin par un custom et migrer le tout après.
De tête je n'ai pas de commande pour ça, en revanche rien ne t'empêche de faire un petit script Batch/VB/AutoIT ou autre qui se base sur subinacl pour exporter les autorisations d'un disque sur un fichier et recherche ensuite les occurrences d'un groupe prédéfini et les ressort dans un fichier log ;) -- Jonathan BISMUTH MCSE 2000/ADSI-AutoIT Scripter Transcript (ID: 691839, code: MCSE2000) www.portail-mcse.net pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" a écrit dans le message de news: %
C'est bien pratique cet outil! si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de remplacer au préalable toutes les permissions basées sur ces groupes par d'autres "customs" que je pourrais migrer ensuite. Existerait t-il une commande (ou un script) pour savoir s'il reste des permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
Patrice.
c'est même l'outil essentiel, tu n'as pas idée :)
Un certain nombre d'admins et consultants l'utilisent exactement pour ce que
tu veux faire afin de remplacer un groupe builtin par un custom et migrer le
tout après.
De tête je n'ai pas de commande pour ça, en revanche rien ne t'empêche de
faire un petit script Batch/VB/AutoIT ou autre qui se base sur subinacl pour
exporter les autorisations d'un disque sur un fichier et recherche ensuite
les occurrences d'un groupe prédéfini et les ressort dans un fichier log ;)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" <nospam@nospam.com> a écrit dans le message de news:
%23xpX4xskFHA.2852@TK2MSFTNGP15.phx.gbl...
C'est bien pratique cet outil!
si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de
remplacer au préalable toutes les permissions basées sur ces groupes par
d'autres "customs" que je pourrais migrer ensuite.
Existerait t-il une commande (ou un script) pour savoir s'il reste des
permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
c'est même l'outil essentiel, tu n'as pas idée :) Un certain nombre d'admins et consultants l'utilisent exactement pour ce que tu veux faire afin de remplacer un groupe builtin par un custom et migrer le tout après.
De tête je n'ai pas de commande pour ça, en revanche rien ne t'empêche de faire un petit script Batch/VB/AutoIT ou autre qui se base sur subinacl pour exporter les autorisations d'un disque sur un fichier et recherche ensuite les occurrences d'un groupe prédéfini et les ressort dans un fichier log ;) -- Jonathan BISMUTH MCSE 2000/ADSI-AutoIT Scripter Transcript (ID: 691839, code: MCSE2000) www.portail-mcse.net pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Patriceg" a écrit dans le message de news: %
C'est bien pratique cet outil! si on peut manipuler aussi simplement les ACL, c'est peut-etre mieux de remplacer au préalable toutes les permissions basées sur ces groupes par d'autres "customs" que je pourrais migrer ensuite. Existerait t-il une commande (ou un script) pour savoir s'il reste des permissions relatives à un groupe/utilisateur dans une arborescence ?
ça évitera les surprises au moment d'arreter l'ancien domaine...
