Re: Migration: undesired password setting; unmigrated group membership

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hello,

Based on my research on this issue, please perform the following things:

1. Verify that the passwords of the source domain user accounts match the
password policy of the target domain.

ADMT cannot verify password policies in the target domain. If the source
user accounts have passwords that violate the password restrictions (such
as minimum length) in the target, then the affected migrated accounts can
log on, but they will be forced to change their password the next time they
log on.

So, I suggest you try matching up the policies on both the sides.
Go to Computer configurations\Windows settings\Security settings\Account
Policies\Password Policy
The "minimum password length" is 8 charaters.
The "Password complexity" and 'Store pwd with reversible encryption" should
still be set to disabled.

2. It is a by design behavior because this password log file could create a
security hole, the "User must change password at next logon" attribute is
set for all migrated user accounts in the target domain.

See figure 9.35 part:
Domain Migration Cookbook
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook
/cookchp9.mspx

Therefore, I recommend that you use the script to uncheck the option and it
will be safer than directly create/change the
"SamRestrictOwfPasswordChange" in the registry and set it to 0.

HTH!

Thanks & Regards

Amanda Wang [MSFT]

Microsoft Online Partner Support

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.

=====================================================================

--------------------
>From: "Rosivaldo Fernandes Alves" <rfa@xxxxxxxxxxx>
>References: <ekOMjV4PFHA.3596@xxxxxxxxxxxxxxxxxxxx>
<PGhf1jAQFHA.3892@xxxxxxxxxxxxxxxxxxxxx>
>Subject: Re: Migration: undesired password setting; unmigrated group
membership
>Date: Mon, 18 Apr 2005 18:09:52 -0300
>Lines: 92
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
>X-RFC2646: Format=Flowed; Original
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
>Message-ID: <OW$6irFRFHA.3496@xxxxxxxxxxxxxxxxxxxx>
>Newsgroups: microsoft.public.windows.server.migration
>NNTP-Posting-Host: jfse.gov.br 200.241.60.42
>Path:
TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1
2.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.windows.server.migration:18449
>X-Tomcat-NG: microsoft.public.windows.server.migration
>
>Dear Amanda,
>
>I have just seen that I didn't say that I successfully imported the
original
>passwords from source domain. By the way, I did this based on the same
link
>you have suggested to me
>(http://support.microsoft.com/default.aspx?scid=kb;en-us;832221). Even so,
>the passwords are imported and immediately expired. Is it really the
>expected behavior? If so, do I really need a script to workaround this?
>Can't I simply create/change the "SamRestrictOwfPasswordChange" in the
>registry and set it to 0?
>
>Please, forgive me for any misunderstanding, since my English is not so
>good.
>
>Forgive my late reply also. I was kept away from this problem for some
time.
>
>Best regards.
>
>Rosivaldo.
>
>"Amanda Wang [MSFT]" <v-amanwa@xxxxxxxxxxxxxxxxxxxx> escreveu na mensagem
>news:PGhf1jAQFHA.3892@xxxxxxxxxxxxxxxxxxxxxxxx
>> Hi Rosivaldo,
>>
>> Thank you for your post.
>>
>> I understand that you want to disable the "User Must Change password at
>> next logon" option when using ADMT to migrate user account with password.
>> If I have misunderstood your concerns, please feel free to let me know.
>>
>> Based on my research, this is a by design behavior. In Windows Server
>> 2003,
>> if password is set using the hash, the "user must change password at next
>> logon" attribute is set automatically by the system. ADMT can not
retrieve
>> the clear text password and use the hash of the password so user was
>> forced
>> to change the password at next logon
>>
>> A workaround is to use a VB script using ADSI to clear that attribute.
The
>> preferred solution is to use a registry key to control this. Although VB
>> script is not supported in this newsgroup, I would like to list the info
>> for your reference:
>>
>> Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
>> Value name: SamRestrictOwfPasswordChange
>> Data type: REG_DWORD
>> Allowed values: 0, 1, 2
>> 0 - old behavior, client can change password through OWF password change
>> API, and the new password remains unexpired.
>> 1 - .NET Server default behavior, client can change password through OWF
>> password change API (SamrChangePasswordUser), but the password expires
>> immediately.
>> 2 -more secure behavior, client can't use OWF password change API. This
>> API
>> (SamrChangePasswordUser) will be totally disabled and return
>> STATUS_ACCESS_DENIED for all clients except for LocalSystem and members
of
>> builtin administrators group.
>>
>> Note:
>> All restrictions are NOT applied to SYSTEM or members of Builtin
>> Administrators Alias Group.
>> If the value of the registry is anything but 0, 1 and 2, the default
value
>> of 1 will be picked.
>> This security setting is an independent control. It does not interactive
>> with the newly introduced extended control access right at all.
>> This security feature works in both DS and Registry cases.
>>
>> If you want to know more on how to write a Script to do this, due to the
>> complexity of programming issues, we are unable to assist with this
>> request
>> in the Partner Support newsgroups. Thank you for your understanding.
>>
>> For further assistance on this issue, please contact Microsoft Product
>> Support Services or post your question on the Microsoft public
newsgroups.
>> Below are these links:
>> http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS
>> http://msdn.microsoft.com/newsgroups/default.asp.
>>
>> For more reference:
>> How to configure the Active Directory Migration Tool to migrate user
>> passwords from a Windows NT 4.0 domain to a Windows Server 2003 domain
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;832221
>>
>> If you have any concerns, please feel free to let me know.
>>
>> Thanks & Regards
>>
>> Amanda Wang[MSFT]
>>
>> Microsoft Online Partner Support
>
>
>

.

Relevant Pages

  • Re: Migration: undesired password setting; unmigrated group membership
    ... do I really need a script to workaround this? ... client can't use OWF password change API. ... > in the Partner Support newsgroups. ... > Support Services or post your question on the Microsoft public newsgroups. ...
    (microsoft.public.windows.server.migration)
  • Re: Scripting problem with ADMT v2
    ... I'm told that running the script on a DC in the target domain will work, ... Target domain DC contacts source domain PDC - as the source domain is NT4, ... utilise this API successfully from a member server (provided it is supplied ...
    (microsoft.public.windows.server.migration)
  • RE: ADMT GROUP command line syntax
    ... Thank you for using Microsoft Newsgroup. ... | Target OU is "Security Groups" (right off target domain root) ... | Why is it looking for a network path in the source domain? ...
    (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: change domain for a dc
    ... Ken Zhao ... Microsoft Online Support ... Microsoft Global Technical Support Center ... Migrate it as a member server to the target domain ...
    (microsoft.public.win2000.active_directory)