Re: Scripting problem with ADMT v2

From: Nick brown (nbrown_at_uk.imshealth.com)
Date: 02/25/04


Date: Wed, 25 Feb 2004 14:15:54 -0000

Bob,

Thanks for looking into this. It is really frustrating that this feature
isn't supported via automation. I've spent a couple of days writing a script
that would really simplify and speed up our migration process, only to find
that the scripting interface will only do half the job that it should (given
that I still haven't found any reference to this limitation in the ADMT
docs). However I shouldn't shoot the messenger ....

I'm told that running the script on a DC in the target domain will work, so
let me see if I've got this right:

DsAddSIDHistory is run locally (on member server/workstation in target
domain)
Target domain DC is contacted
Target domain DC contacts source domain PDC - as the source domain is NT4,
authenticates using NTLM (in your reply you said "If the target domain is
NT4, the trust relationship is NTLM", but it only makes sense if you meant
"if source domain is NT4") - using supplied credentials if GUI was used, or
anonymous if script was used

I'm not sure how running the script on a target domain DC overcomes the
problem (if it does). Surely, even if I run the script on a target domain
DC, the authentication process from the target domain DC to the source
domain PDC will still be NTLM as above?

Also, this implies that it's not a limitation of DsAddSIDHistory (that it
should be called from a DC in the target domain). If the ADMTv2 tool can
utilise this API successfully from a member server (provided it is supplied
with the correct credentials for the NTLM auth) then maybe it's possible to
create a COM wrapper to do the same. I could then copy the SID after the
ADMT has done its stuff?

Any other workaround that you can suggest?

Cheers, Nick.

"Bob Qin [MSFT]" <bobqin@online.microsoft.com> wrote in message
news:0fCF945%23DHA.612@cpmsftngxa06.phx.gbl...
> Hi Nick,
>
> Thanks for your update.
>
> I have contacted one senior engineer for this issue, he said this is
> problem was caused because we do not support credentials in the scripting
> and command line interfaces.
>
> In more detail, the issue is as follows:
>
> To migrate SID History, the person running the migration must be an
> administrator in the source domain
> If you are running ADMT on a member server, you are calling the
> DsAddSIDHistory API locally on the member server
> The member server will now contact a DC in the target domain and call the
> remote stub of the API (through an RPC call)
> On the DC, the RPC server will now contact the PDC in the source domain.
> If the target domain is NT4, the trust relationship is NTLM
> If NTLM is used, Kerberos delegation cannot be used, which means that the
> call uses anonymous credentials
> If you used the GUI on the member server, you can use a dialog box to
> supply credentials of the source domain administrator
> When the call is remoted to the target DC, the target DC can use the
> credentials to logon as administrator in the source domain, therefore, it
> succeeds if you use the GUI
> If you use scripting on the member server, you cannot supply credentials,
> which means that the remoted call will logon to the source DC as
anonymous,
> which means that SID History migration will fail
> The command line uses the scripting interface
>
> Hope the information helps.
>
> Regards,
> Bob Qin
> Product Support Services
> Microsoft Corporation
>
> Get Secure! - www.microsoft.com/security
>
> ====================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ====================================================
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>



Relevant Pages

  • Re: Migration: undesired password setting; unmigrated group membership
    ... ADMT cannot verify password policies in the target domain. ... Microsoft Online Partner Support ... do I really need a script to workaround this? ...
    (microsoft.public.windows.server.migration)
  • Re: Scripting problem with ADMT v2
    ... problem was caused because we do not support credentials in the scripting ... If you are running ADMT on a member server, ... the RPC server will now contact the PDC in the source domain. ... If the target domain is NT4, ...
    (microsoft.public.windows.server.migration)
  • Re: Scripting problem with ADMT v2
    ... Target domain DC contacts source domain PDC - as the source domain is NT4, ... I'm not sure how running the script on a target domain DC overcomes the ... able to logon onto the source PDC using the caller¡¯s implicit credentials ...
    (microsoft.public.windows.server.migration)
  • Re: Inter-Forest Password Migration between 2 AD
    ... My target domain is a 2003 domain. ... > We need to run Pwdmig.exe on the source domain DC and install ADMT on the ... > on which you installed ADMT: ... Type the following command to create the encryption key to be used ...
    (microsoft.public.windows.server.migration)
  • RE: Inter-Forest Password Migration between 2 AD
    ... We need to run Pwdmig.exe on the source domain DC and install ADMT on the ... The Target domain need to be native mode. ... on which you installed ADMT: ... Type the following command to create the encryption key to be used ...
    (microsoft.public.windows.server.migration)