We Keep Coding

LDAP Password reset does not respect the pwdhistory attribute

I'm using Java - Apache Directory Client API for accessing Apache DS Ldap Server using ldapConnectionTemplate.
I'm trying to implement a feature which allows the user to reset/change the password. My password policy has a password history attribute value of 5. So user will not be able to use any of the previous 5 passwords.
When I'm using the modifyPassword method for changing the password(i.e. as a user by passing current and new password), it respects the password history policy. i.e I'm not allowed to use any of the previous 5 passwords and getting password exception as expected. But when using the reset option(i.e. - only new password), it does not honor the password policy. It accepts any value(including current one) and updates the password.
How to make the reset password scenario honor the password history policy? Any ideas, suggestions and solutions are welcome.

I don't believe the behaviour you desire is specified anywhere.
The idea of a 'reset' in the sense you mean is that the admin sets it to something known, tells the user what it is, and the pwdReset attribute is set to TRUE so that the user is forced to immediately change it on next login - which you have to enforce yourself by using the PasswordPolicy request control and inspecting any PasswordPolicyResponse for CHANGE_AFTER_RESET.
There's no particular reason why the admin should be constrained by the pwdHistory, and anyway the user is going to be forced to change the password again anyway, at which time he will be constrained by pwdHistory.

How to reset password in AD, getting an LDP OperationNotSupported error

We are able to create accounts in the active directory. But for some reason we are unable to login with them. The way our system works is a user applies for an account, an admin approves it and the user is sent a temporary password to login with.
We think it may have to do with the permissions of the user but are not quite sure. Our code is extensive but here is some of our code and console log:
javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 0000052D: SvcErr: DSID-031A120C, problem 5003 (WILL_NOT_PERFORM), data 0
We are using the same random password generator listed in this previous post:
How to generate a random alpha-numeric string?
Java
RandomPassword randPass = new RandomPassword(11);
String temporaryPassword = randPass.nextString();
Attribute password = new BasicAttribute("unicodePwd", formatPassword(temporaryPassword));
The formatPassword function comes from this article:
http://www.ramblingtech.com/will_not_perform-error-from-ad-on-password-change-using-java/

The problem was that the randomly generated password did not meet the requirements set by the AD.

Programmatic testing of API proxies

I was evaluating the APIGEE proxy apis and accessing by programmatic deploy and invoke.
I downloaded the sample programs (api-pltform-samples-master). While testing the simpleProxy, I ran the deploy.sh and kept receiving the error:
Deploying to test on https://api.enterprise.apigee.com using batabya and batabya
Writing ../simpleProxy/deploy.sh to ./deploy.sh
Writing ../simpleProxy/invoke.sh to ./invoke.sh
Writing ../simpleProxy/apiproxy/weatherapi.xml to apiproxy/weatherapi.xml
Writing ../simpleProxy/apiproxy/proxies/default.xml to apiproxy/proxies/default.xml
Writing ../simpleProxy/apiproxy/resources/jsc/changeResponse.js to apiproxy/resources/jsc/changeResponse.js
Writing ../simpleProxy/apiproxy/resources/jsc/generateResponse.js to apiproxy/resources/jsc/generateResponse.js
Writing ../simpleProxy/apiproxy/resources/jsc/MashItUp.js to apiproxy/resources/jsc/MashItUp.js
Writing ../simpleProxy/apiproxy/resources/py/calculateAddress.py to apiproxy/resources/py/calculateAddress.py
Writing ../simpleProxy/apiproxy/resources/py/setHeader.py to apiproxy/resources/py/setHeader.py
Writing ../simpleProxy/apiproxy/resources/py/Timer.py to apiproxy/resources/py/Timer.py
Writing ../simpleProxy/apiproxy/resources/xsl/rewriteEndpoint.xsl to apiproxy/resources/xsl/rewriteEndpoint.xsl
Writing ../simpleProxy/apiproxy/targets/default.xml to apiproxy/targets/default.xml
Import failed to /v1/organizations/batabya/apis?action=import&name=weatherapi with status 401:
If 'State: deployed', then your API Proxy is ready to be invoked.
Run '$ sh invoke.sh'
If you get errors, make sure you have set the proper account settings in /setup/setenv.sh
FYI: I have created my profile with admin rights.

The 401 error indicates an issue with authentication. There are 3 factors that comprise authentication here: (1) organization name, (2) username and (3) password.
The (1) organization name and (2) are username are configured in setenv.sh. The (3) password is prompted for from deploy.sh.
Make sure you have set your org and username by modifying the following two lines in setenv.sh :
org="Enter the name of your organization here"
username="Enter your Apigee username"

One important clarification:
username="Enter your Apigee username"
This value needs to be the email address associated with your account on enterprise.apigee.com.
We'll update the README to clarify this.

Ldap password policy not throwing different errors

I use ppolicy overlay and enabled ppolicy_use_lockout to separate between invalid password and locked accounts.
database bdb
suffix "dc=openiam,dc=com"
rootdn "cn=Manager,dc=openiam,dc=com"
rootpw "{SSHA}2ttRoo/t5HuMT2nPxtI6goVUML5R2H9h"
# PPolicy Configuration
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=openiam,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext
I tried to lock user account by entering wrong password couple of times (pwdMaxFailure)
The user is being locked but when I try to login again I still get the same error:
Invalid credentials (49)
Any idea why i am not getting diffrent error to disticnt between the cases?
thanks,
ray.

you should add -e ppolicy when use ldapwhoami to get more information like (Password expired, 3 grace logins remain)

You will get a password policy response control that tells you the error, if you request it with the corresponding request control.
Note that it's a bad idea to let this show through to the user, for the reasons stated in the password policy draft, section 12. Basically you would be leaking information to an attacker.
Note also that this technique also applies to my answer to your previous question which I have now corrected.

How to fix Trust Boundary Violation flaw in Java Web application

I am receiving a Trust Boundary Violation from Veracode.
My code is
userName= req.getParameter(Constant.USERNAME);
session.setAttribute(Constant.USERNAME, userName); //At this line i am getting Trust Boundry Violation flaw.
How can I validate userName to avoid a trust boundary violation flaw?

Simply use a regular expression to validate the userName according to the rules your usernames follow:
if(userName.matches("[0-9a-zA-Z_]+")
session.setAttribute(Constant.USERNAME, userName);

VeraCode will require you to file a mitigation with them. They will schedule a consultation with you and there you can show them the code fix(s) implemented and they will then mark the mitigation approved.
Yes, I know this is late but others may trip through and it needs to be pointed out.

Trust boundary violation happens when user input is set into session. Using this flaw attacker can set any other username in to session and can cause impersonation. Where ever username is accessed is code from session(session.getattribute) will give attacker privileges of that user.
Mitigation: before setting user input into session, make sure that username that is set in to session is of authenticated user.

Validate your data using ESAPI.validator().getValidInput(...) and then set the value into a session object.