Sign in with
Sign up | Sign in
Your question

Use an LDAP user to create another LDAP user

Last response: in Windows 2000/NT
Share
Anonymous
March 30, 2005 11:01:02 PM

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.
Anonymous
March 31, 2005 10:57:40 AM

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.
Anonymous
March 31, 2005 10:57:41 AM

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.
Related resources
Anonymous
March 31, 2005 9:26:39 PM

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.
Anonymous
May 20, 2005 7:35:19 PM

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.
!