RE: ADSI question

From: Paul Aviles (
Date: 08/27/04

  • Next message: Eric Peeters: "Password policy enforcement tools was RE: ADSI question"
    Date: Fri, 27 Aug 2004 11:32:14 -0400
    To: "c0ncept" <>

    That is opposite to my experience. An old client in Fla had an NT 4.0
    domain that migrated to new AD. After users migrated some of them could
    not log in and we needed to reset the passwords. We used Bindview tools
    for the migration. Others, please any feedback?

    -----Original Message-----
    From: c0ncept []
    Sent: Friday, August 27, 2004 11:26 AM
    To: Paul Aviles
    Subject: RE: ADSI question

     AFAIK it won't disable them; enabling strong
    passwords doesn't muck with the existing passwords, it essentially turns
    on a flag that causes the GUI / password API to reject non-strong
    passwords. This is analogous to checking your data integrity in an
    application instead of a database. We used a migration tool to upgrade
    our domain and migrate it into an existing forest at the same time. The
    existing forest had enabled strong passwords, but we hadn't on our
    domain. After the migration, our users could continue using their weak
    passwords, until the first time the password expired, then they were
    forced to choose a strong password.

    --- Paul Aviles <> wrote:

    > Arthur thanks,
    > Well, is for documentation purposes. For audit and documentation
    > purposes it needs to be done. The client is on AD
    > already but if we
    > enable strong password doesn't that mean that all
    > the passwords that do
    > not meet the criteria get disabled? That has been my
    > experience in the
    > past..
    > Thanks
    > -pa
    > -----Original Message-----
    > From: []
    > Sent: Wednesday, August 25, 2004 8:13 PM
    > To: Paul Aviles;
    > Subject: RE: ADSI question
    > I don't believe you can use ADSI to accomplish that.
    > That's a pretty
    > useful idea, but definitely a security risk. The
    > closest you probably
    > can come to that is to perhaps run the MBSA tool
    > against your server. I
    > know that it reports if a user has a weak or a blank
    > password for SQL,
    > but I am not certain about the domain passwords. A
    > more drastic approach
    > would be to run a password cracker against your SAM
    > and see what types
    > of passwords are out there.
    > But I don't really understand why you need to do
    > that. I am sure someone
    > will correct me if I am wrong, but complexity
    > requirements are enforced
    > when a password is changed or created. Existing
    > passwords can remain the
    > same. New rules will apply when the passwords expire
    > or a new account is
    > created.
    > You are correct about the install of AD in the new environment. As far
    > as the in-place upgrade, my best guess is that
    > Windows 2003 will enable
    > the complexity requirements regardless of your
    > previous security policy.
    > It shouldn't be too much of a problem though. You
    > can leave the policy
    > in place and wait for user's password to expire or
    > you can disable it
    > right after your upgrade completes.
    > Arthur Freyman
    > -----Original Message-----
    > From: Paul Aviles []
    > Sent: Wednesday, August 25, 2004 9:31 AM
    > To:
    > Subject: ADSI question
    > Is it possible to use ADSI to query user accounts
    > and find if they are
    > using a strong password? Before using GPO's to
    > enable it, I need to have
    > an audit and show how many people don't have them.
    > Is this a property
    > of the users?
    > Also, I believe that when you install AD in a new
    > environment by default
    > it has strong password enabled. Is that the same
    > when you do an in place
    > migration?
    > Thanks
    > Paul
    > ---
    > ---


  • Next message: Eric Peeters: "Password policy enforcement tools was RE: ADSI question"

    Relevant Pages

    • RE: SidHistory and password migration with ADMT
      ... SidHistory and password migration with ADMT ... |- added to registry ... |passwords are blanks. ...
    • SidHistory and password migration with ADMT
      ... added to registry ... passwords are blanks. ... 2004-02-25 10:47:54 W1:7392 SIDHistory could not be ... The Active Directory Migration Tool will not attempt to ...
    • RE: ADMT password migration between 2 2003 servers using Version 3
      ... appear to update unless I get all the way through the migration process. ... but did not try to migrate passwords. ... Source Disable Option: Leave source account ... Target Disable Option: ...
    • Re: Saved passwords lost after ADMT profile translation
      ... I'm not talking about cookie-based passwords or stuff lost from TIF. ... The migration method follows exactly what is described here: ... Possible on the migration method. ... > destination the cookies would still be in place for web site logon. ...
    • ADMTv2 -- Password Migration problem
      ... I am having a problem migrating passwords with ADMTv2 and I don't know ... Migrating one domain to another domain in an INTER-FOREST migration with the ... install admt and create admt key for PES server ... On Source PDC, installed admt, and install passwd migration using KEY ...