Use an LDAP user to create another LDAP user

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
Siemel said:
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.
Click to expand...

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.
 
Brandon McCombs said:
Siemel Naran wrote:

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.
Click to expand...

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.
 
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.
Click to expand...
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.
 
Paul Nelson said:
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.
Click to expand...

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.
 
Back
Top