Use an LDAP user to create another LDAP user

Archived from groups: microsoft.public.win2000.active_directory (More info?)

In our application, we use an LDAP user to create another LDAP user. Here is
our architecture: We log in to our own application and request it to create a
new user, then it calls ldap_add_s to add a user. Our application logs in to
the LDAP server as AppsUser123, but the request to add a new user fails with

LDAP_UNWILLING_TO_PERFORM
0x35 The server is not willing to handle directory requests.

The event viewer security log below shows we log in as AppUser123

Special privileges assigned to new logon:
User Name: AppUser123
Domain: QA1-QATEST
Logon ID: (0x0,0x4893D30)
Privileges: SeChangeNotifyPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeDebugPrivilege

Maybe AppsUser123 does not have the correct privileges.

How can I go about debugging and fixing the problem?

Thanks.
4 answers Last reply
More about ldap user create ldap user
  1. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Siemel Naran wrote:

    > In our application, we use an LDAP user to create another LDAP user. Here is
    > our architecture: We log in to our own application and request it to create a
    > new user, then it calls ldap_add_s to add a user. Our application logs in to
    > the LDAP server as AppsUser123, but the request to add a new user fails with
    >
    > LDAP_UNWILLING_TO_PERFORM
    > 0x35 The server is not willing to handle directory requests.

    This can happen if you have password policies in place and you are adding a user
    with a blank password. This error same error can occur if you are importing
    users from a csv file using csvde. It will NOT import passwords by design so if
    you have password policies set you have to disable them otherwise you get
    "Unwilling to perform". Sounds like that's what is happening in your case.

    >
    >
    > The event viewer security log below shows we log in as AppUser123
    >
    > Special privileges assigned to new logon:
    > User Name: AppUser123
    > Domain: QA1-QATEST
    > Logon ID: (0x0,0x4893D30)
    > Privileges: SeChangeNotifyPrivilege
    > SeBackupPrivilege
    > SeRestorePrivilege
    > SeDebugPrivilege
    >
    > Maybe AppsUser123 does not have the correct privileges.
    >
    > How can I go about debugging and fixing the problem?
    >
    > Thanks.
  2. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    "Brandon McCombs" wrote:
    > Siemel Naran wrote:

    > > In our application, we use an LDAP user to create another LDAP user. Here is
    > > our architecture: We log in to our own application and request it to create a
    > > new user, then it calls ldap_add_s to add a user. Our application logs in to
    > > the LDAP server as AppsUser123, but the request to add a new user fails with
    > >
    > > LDAP_UNWILLING_TO_PERFORM
    > > 0x35 The server is not willing to handle directory requests.
    >
    > This can happen if you have password policies in place and you are adding a user
    > with a blank password. This error same error can occur if you are importing
    > users from a csv file using csvde. It will NOT import passwords by design so if
    > you have password policies set you have to disable them otherwise you get
    > "Unwilling to perform". Sounds like that's what is happening in your case.

    Thanks, I'll look at the password policies tomorrow. Though I should
    mention that the only policy I'm aware of is that the password be 4 or more
    chars, and my password is 5 or 6 chars. Where does one view and set the
    password policies? Thanks again.
  3. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    in article 5F0BB059-CB60-4506-B94C-EE034AF5B906@microsoft.com, Siemel Naran
    at SiemelNaran@discussions.microsoft.com wrote on 3/31/05 1:27 AM:

    > "Brandon McCombs" wrote:
    >> Siemel Naran wrote:
    >
    >>> In our application, we use an LDAP user to create another LDAP user. Here
    >>> is
    >>> our architecture: We log in to our own application and request it to create
    >>> a
    >>> new user, then it calls ldap_add_s to add a user. Our application logs in
    >>> to
    >>> the LDAP server as AppsUser123, but the request to add a new user fails with
    >>>
    >>> LDAP_UNWILLING_TO_PERFORM
    >>> 0x35 The server is not willing to handle directory requests.
    >>
    >> This can happen if you have password policies in place and you are adding a
    >> user
    >> with a blank password. This error same error can occur if you are importing
    >> users from a csv file using csvde. It will NOT import passwords by design so
    >> if
    >> you have password policies set you have to disable them otherwise you get
    >> "Unwilling to perform". Sounds like that's what is happening in your case.
    >
    > Thanks, I'll look at the password policies tomorrow. Though I should
    > mention that the only policy I'm aware of is that the password be 4 or more
    > chars, and my password is 5 or 6 chars. Where does one view and set the
    > password policies? Thanks again.
    >
    Unwilling to perform can also be returned if you are attempting to change an
    attribute that is "owned" by the security system. You should create the
    account with the bare minimum attributes, then modify it to change other
    stuff as needed.

    Paul Nelson
    Thursby Software Systems, Inc.
  4. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    "Paul Nelson" wrote:

    > Unwilling to perform can also be returned if you are attempting to change an
    > attribute that is "owned" by the security system. You should create the
    > account with the bare minimum attributes, then modify it to change other
    > stuff as needed.

    The problem was actually a flaw in Windows 2003.

    We were setting userAccountControl first then unicodePwd -- meaning that in
    ldap_add_s(LDAP* ld, PCHAR dn, LDAPMod* attrs[]), attrs was for
    userAccountControl and attrs[j] for unicodePwd with i < j. This works fine
    in Windows 2000. It will work fine in Windows 2003 after they release a new
    hotfix that is currently in beta testing, but which we used to verify that it
    fixes the problem.

    The workaround is to set unicodePwd first, then set userAccountControl, then
    set unicodePwd again so that the flag "User must change password at next
    logon" be set to false.
Ask a new question

Read More

Login Servers LDAP Active Directory Windows