Using ADSIedit to set an ADAM users password

Discussion in 'Active Directory' started by gplantz, Oct 13, 2004.

  1. gplantz

    gplantz Guest

    Hi Folks,

    A Newbe question. Can an ADAM Users password only be set programmatically?
    Or can the password be set with ADSIedit?


    gplantz, Oct 13, 2004
    1. Advertisements

  2. I'm going to quote a post from Dmitri Gavrilov that explains how things work
    in ADAM. The net result is that you should be able to use ADSIEdit to
    change userPassword, depending on your settings. There are also some
    channel encryption requirements to set the password, although they can be
    modified with other settings.

    Joe K.

    (from Dmitri)

    It's a bit complicated.

    unicodePwd is the "real password attribute", in both AD and ADAM. That's
    what is used for user binds. It has a very specific formatting requirements.
    Whenever you set a value, it must be a unicode string enclosed in double

    userPassword is "switchable". It can be turned into a regular attribute, or
    it can be turned into a write-alias for unicodePwd. AD by default has it as
    a regular attribute. ADAM by default has it as a unicodePwd alias. This is
    controlled by the 9th char of dsHeuristics. 0 is the default (different in
    AD w2k3 and ADAM). 1 means "userPassword is write-alias for unicodePwd", 2
    means "userPassword is a regular attribute".

    When userPassword is a write-alias for unicodePwd, it is written as a
    regular value, no unicode, no double-quotes. However, passwords can never be

    When userPassword is a regular attribute, you can read and write it, but you
    can not bind with it.
    Joe Kaplan \(MVP - ADSI\), Oct 13, 2004
    1. Advertisements

  3. gplantz

    Lee Flight Guest

    As Joe Kaplan pointed out you can use ADSIedit.

    Right click the user object -> Reset Password

    As Joe also pointed out there is a secure channel
    requirement for password operations. So if your ADAM
    instance is on a standalone machine (outside of a domain)
    your only option for the secure channel is SSL, ADSIedit
    does not handle that so you will need to disable the secure
    channel requirement to be able to use that aspect of the tool
    in that case. Using ldp.exe you can use SSL and so perform
    password operations without changing the default requirement.

    Lee Flight
    Lee Flight, Oct 13, 2004
  4. gplantz

    Lee Flight Guest

    On the subject of userPassword, I do wonder why the MSDN sample
    for setting an ADAM user password did not use that rather than the
    Invoking SetPassword. Modifying the default dsHeuristics on W2K3
    to allow use of userPassword is something that seems unpopular too,
    everyone seems to use either SetPassword or encoding the unicodePwd.
    Could it be a concern about treating the password as just another attribute
    and that a tendency to disable the secure channel requirement might follow?

    Joe, given the amount of good work you have done sorting out problems
    in this area have you any thoughts on the use of userPassword as above
    or is it just too ADAM / W2K3 centric at present?

    Lee Flight
    Lee Flight, Oct 13, 2004
  5. Hi Lee,

    I'm not sure why the MS folks decided to push SetPassword as the standard
    method to do password work in ADAM. It can be very hard to get to work in
    AD because it is so complex under the hood, and it tends to get even more
    complex in ADAM. I tend to believe that it is more straightforward and
    easier to diagnose to just get the password attributes directly and simply
    "know" that you need to set up an encrypted channel in advance.

    You do a lot more ADAM work than I do (which is very little so far except
    for some dabbling here and there), so I don't have really strong feelings
    here yet. However, I generally always set unicodePwd directly when I need
    to do password work.

    The reason I use that is:
    - it works pretty uniformly in AD and ADAM
    - building the unicode byte array that it needs is pretty easy in .NET
    (which is all I program in)
    - setting up the encrypted channel isn't hard
    - you can also use ldp.exe to perform the same thing by using the special
    \UNI: syntax in the attribute value for the mod operation.

    I also think this approach has some advantages in that you can explain it to
    people who aren't using ADSI as their API.

    Personally, I'd like to see more work done by MS in this area. Password
    management is pretty hard for both AD and ADAM in many areas, and diagnosing
    problems in the provided APIs is pretty difficult.

    My $0.02

    Joe K.
    Joe Kaplan \(MVP - ADSI\), Oct 13, 2004
  6. gplantz

    Lee Flight Guest

    Thanks for your thoughts on this, your rationale for unicodePwd
    below is the same for userPassword for those only dealing with
    just ADAM and W2K3. I guess given that rationale we may not
    see much more development in this area as it would only benefit
    W2K assuming that MS will switch to promoting userPassword
    as the way to go (which begs my original question as to why
    it was not in the MSDN sample for ADAM).

    On reflection I guess one has to consider ChangePassword as
    well. I have never tried that with userPassword which would need
    to mimic the usual two-step delete/add done with the LDAP API
    for the unicodePwd. Of course the Invoke method handles that in
    this case which is all I have ever used for ADAM ChangePassword,
    maybe that goes part of the way to explaining the advocacy. The
    alternative I suppose is to build ChangePassword as an "authenticate
    existing password" and then reset to new using a trusted account.

    Thanks again
    Lee Flight
    Lee Flight, Oct 13, 2004
  7. WRT change password: using a trusted account is not clean wrt auditing. And,
    afaik, ADSI does not support deleteValue/addValue mod pair required for ldap
    ChangePassword operation. That's the primary reason for using a separate
    API. And then SetPassword just follows.

    From my prespective, pwd operations are fairly clean if you do them in ldap.
    ADSI arguably has been hacked at the last moment to support Set/ChangePwd
    api in ADAM. It used to hardcode ports, as well as the multi-step process
    for pwd changes (kerberos, netapi, then ldap, if I remember correctly). So,
    they had to add these strange SetOption calls to make it work for ADAM. I
    can understand why they did this for AD -- pwd operations are
    security-sensitive and should be done in the most secure way if possible.
    But going after security, they have given up compatibility.

    To tell you the truth, I don't even know if Change/SetPwd will be even
    available if you define your own user class that is not called "user" or
    "inetOrgPerson". Perhaps you can get it by tweaking registry manually? I
    mean you need to get IADsUser instantiated. In ADAM we introduced a new
    approach based on msDS-bindableObject aux class, for better or for worse.
    ADSI is not aware of that.

    This does require some work indeed.

    Dmitri Gavrilov
    SDE, Active Directory Core

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    Dmitri Gavrilov [MSFT], Oct 13, 2004
  8. This is a good point about ChangePassword and the operations needed to make
    it work in ADSI. I think I've tried to get "ChangePassword" functionality
    working in ADSI/.NET by calling PutEx directly, but I couldn't make it go.
    I think you really do need to create the proper LDAP mod ops to do this.

    I'm hopeful that the new System.DirectoryServices.Protocols stack for .NET
    2.0 will make operations like this more straightforward. That should help a
    lot from the API accessibility standpoint.

    The larger issue for user object extensibility in ADAM and bind support does
    seem to be something that you guys will need to work on if you are going to
    provide a more general solution.

    Regarding the mechanics of SetPassword and ChangePassword, for SetPassword
    it goes LDAPS first, then Kerberos, then NetUserSetInfo (if a call to
    LogonUser succeeds in the case that credentials were supplied). For
    ChangePassword, it goes LDAPS first, then NetUserChangePassword. I guess
    there is no Kerberos option available for password changes?

    I like how easy these APIs are to call. What I don't like is that they are
    hard to figure out why they didn't work when they don't because they try so
    many different things which all have a variety of different ways they can
    fail. SetPassword uses three different approaches which use three different
    network ports and may vary quite a bit depending on execution context, so
    lots of weird issues come up.

    The fact that you have to do all those SetOption calls to make it work for
    ADAM leads me to agree that the solution is still a bit too "hackish" for
    ADAM and needs some more thought.

    Hopefully someone there is thinking about this stuff (Andy?).

    Joe K.
    Joe Kaplan \(MVP - ADSI\), Oct 13, 2004
  9. Thanks Joe. I have forwarded the thread to Andy.

    Dmitri Gavrilov
    SDE, Active Directory Core

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    Dmitri Gavrilov [MSFT], Oct 13, 2004
  10. gplantz

    Greg Martin Guest

    Joe, Dimitri & Lee,

    In the short time I've been playing with ADAM, I've discovered that password
    issues are often discussed in this group and the three fo you spend a fair
    amount of time answering the questions from us newbies. Would the three of
    you consider compiling a FAQ to cover this issue?

    There have been some excellent discussions here. I hate to see them get
    "lost" as they epire off the news server (I don't read it through google

    Thanks each of you for the help you provide here.

    Greg Martin, Oct 25, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.