LDAP Password Policy - Syntax

Hi,
I am trying to find out if there is a way to define password syntax rules from within the LDAP server (I am using IPlanet version 5.1 Service Pack 2).
The password syntax used at my company specifies that all passwords must contain at least one lowercase letter, one uppercase letter, and one number. Also, passwords may not contain any part of the username or any part of the user's full name.
Is there a way to get the LDAP server to perform these checks? And if so, how?
Thanks!

DS does not support this at the server level. You may have to build a pre-op plugin

Similar Messages

Password Policy Syntax

I need to set up a password policy where both uppercase and lowercase letters must coexist in the selected password.
I haven't seen this option in the password parameter fields in OID.
Is it possible to specify a additional or different password syntax rule?
Oriol

Which version of OID are you using. e.g. with 10.1.4. you can specify/configure this in OID.
regards,
--Olaf

Using class of service to manage password policy

We implemented password policy on our old DS across the board, which entailed finding all of the special administrative accounts used by software and setting an expiration date at the end of the epoch. I was wondering if a smarter way to do this is to create a class of service template for normal and special accounts and tie those into our user accounts. Has anyone done this?
Thanks.

Sun DS 5.2 supposedly has support for the latest LDAP password policy internet draft which allows you to explicitly setup password policy on a subtree or user basis. It uses roles and class of service under the covers. I would use that instead of rolling your own.

Password Policy : PwdMustChange problem

Hi,
i'm facing some strange issues with the password policy under Oracle Directory Server v6.3.
I modified the global policy to force user to change their password after administrative reset.
In the policy i see PwdMustChange set on TRUE.
The problem is that it has no effects on users.
I use several administrative accounts (including directory manager) to change user password (made a reset) and it is still possible to log with their account.
I don't get it, it's like the property PwdMustChange had no effect.
Has anyone faced this problem??
Thanks

The "must change" state does not prevent a user from logging in. It only requires that the next LDAP operation that the user does on that open connection be a MOD where the user changes his own password. All subsequent operations other than the password reset will fail (most likely with err=53 - DSA Unwilling To Perform).
However, many applications will not do anything subsequent as the user. In other words, the BIND will succeed and then the application will go on about its business servicing the user, because the way the application code is written, it doesn't need to do anything other than the BIND to authenticate the user, and the BIND has succeeded.
When an LDAP-enabled application is going to integrate with the LDAP password policy model, it needs to consume LDAP controls properly. In this case, the BIND request and response should include a password policy control that indicates the user must reset his password. This is how, even in the case of an application that need not do anything except BIND, the password policy functionality can work.
If you want to verify that the server's password policy is working, you can do it in a number of ways. If you have the audit log turned on, when the administrative reset occurs, you should see some server-side modifications to the user that set a "must reset" operational attribute. If you do ldapsearch as the user, you should get an informational message that the search has failed. Depending on which ldapsearch tool you use, you may get a fairly informative message about the user needing to reset his password and/or the server being unwilling to service the SRCH request. If your ldapsearch as the user succeeds immediately after the admin reset, then the server password policy is not set up correctly.

Password Policy User not locked

After 3 wrong password attempts. User account are not locked out.
- Password policy is enabled
- validate_password plugin include obReadPasswdMode="LDAP", obWritePasswdMode="LDAP"
- Password Policy Cache is flush.
Anything else i should look into?
thankx

You may want to check the password policy filter to ensure your user is being picked up by the policy.
is the oblogintrycount attribute being incremented?

How to create a password policy for password syntax?

Hi,
I need to apply a password policy in OID that checks the password syntax. We need to verify that the each password contains at least three of the four character groups (Capital Letters / Small Letters / Numbers / Special Characters). In OID, I may only check for minimum Length and a min Number of Numbers. Is there an easy way to do this? (Plugin in OID?)
For the Web-Part (eg. Portal) its quite easy, as we may create a Javascript to check the syntax on the "change password" page, but as we have diffrent types of access, we want to get the rule applied in one place.
Thanks for help
Alex

Hi,
In addition to Martin’s suggestions, we can also choose to change the scope of the existing GPO with Security Filtering.
Regarding Security Filtering, the following article can be referred to for more information.
Security filtering using GPMC
http://technet.microsoft.com/en-us/library/cc781988(v=WS.10).aspx
Filter Using Security Groups
http://technet.microsoft.com/en-us/library/cc752992.aspx
Best regards,
Frank Shen

Linux and Solaris Clients with password policy using LDAP

Anybody managed to get Linux (RHEL) and Solaris 9 Client authenticate against Sun Directory Server 5.2p4 using the same password policy?
For me it looks like Linux needs attribute shadowlastchanged set to display proper Warnings, that the password will expire/needs to be changed now. On the other hand Solaris (using pam_ldap) never writes this attribute, because it's using the password policy attribute pwdchangedtime.
Hints very wellcome!
Can anybody confirm Solaris9 pam_unix still sets this shadow* attributes correct on any password change executed by a user?

Hi Jeremy,
here the answers to your questions:
>My question is which system takes precedence over the password policy?
Unfortunately there is no policy verification between the portal and your Sun One LDAP. So if you reset the password from the portal then only the portal password policies can be checked.
> If I wanted to do password resets from the Portal, does the portal then store only the password in its database?
No, the password will be stored in the LDAP, but only if it also corresponds with the LDAP policies. If not, then you will get an error, but you will not see the real LDAP exception.
> Also what would then happen if you tried to reset the password from the LDAP?
The password in the LDAP does not have to fit to the Portal password policies. When you log in, the portal will only check if the password you tipped in is the new one in LDAP and will not check any policies.
Hope this brings some light in,
Robert

How to retrieve a password policy response after a ldap bind operation

Background:
I've set up openldap with the ppolicy overlay. The overlay works as expected, but after a bind operation I need to get hands on the ppolicy response.
This can be done manually (with shell commands like ldapsearch) by specifying '-e ppolicy' (general extension).
But how can i get hands on response from my LoginModule? Code:
env.put(Context.SECURITY_PRINCIPAL, userDN);
env.put(Context.SECURITY_CREDENTIALS, inputPassword);
ctx = new InitialLdapContext(env, null);
..is it possible to use ExtendedRequest or UnsolicitedNotificationEvent when the creation of the context throws a NamingException (the bind operation fails due to a locked account).
Thanks in advance!
J�rgen L�kke

Hi,
I am having the exact same problem in that OpenLDAP is implementing the password policy people login and everything is fine, but then the password expires and bang they are out. I would like to be able to give my users some warning to say that their password will expire in x days or that your password has expired you have X logins left.
Anyway I have tried the methods suggested here and using ctx.getResponseControls() will either give me null or an array with the exact same objects that I passed in with new InitialLdapContext. What I have did work fine when we used the old jar libraries but we moved to JNDI.
Any help would be appriciated

Issue with Lockout Duration in Password Policy in OAM

Hi,
We are facing an issue with the lockout duration configuration in the password policies in the identity manager interface for our OAM setup.
Oracle Access Manager 10g version 10.1.4
User/Policy Store: ADAM Ldap [Microsoft ADAM 2003]
After we lock out a user in our LDAP after 5 wrong attempts, the two attribute values in ADAM get updated to 5:
oblogintrycount
badPwdCount
Also I see that "oblockouttime" gets updated with an unix timestamp.
Now, we have set the "Lockout Duration" in the password policy as 1 hour. So, after 1 hour, the user should be unlocked in ADAM.
However, after 1 hour when the user tries to login, he/she gets the error that a wrong password has been entered for the userID.
When we check in ADAM, we see that the value of "oblogintrycount" was indeed reset. However the value of "badPwdCount" did not get reset and is still stuck at 5.
If we reset both these attribute values to 0, the user can login again.
Now, is OAM expected to reset both these attribute values to 0, or does it only reset the oblix attributes?
If it is the latter, is there a way around to resolve this issue? Or are we doing something wrong here?
Please let us know your feedback.
Thanks!
Abhishek.

OAM only works with the ob* attributes, and not with badPwdCount attribute of the AD (ADAM). I think for some reason the password and account policies of the AD is being triggerred. Disable the AD password policy and it will be Ok.
Hope this helps. Let us know.

Fine-Grained Password Policy problem

Hi All,
I'm testing a Fine-Grained Password Policy for a group of users.
I created a test PSO using ASDI Edit and applied the PSO to a global security group.
Test user has been added to this group.
The PSO settings include "Enforce password history: 5"
The user has changed the password.
After 24h when I logged in as the user and changed the password - for example: Password1.
After another 24 hours I changed the password to Password2.
One day later I've been asked to change the password again.
In theory I shouldn't be able to use any of the 5 previous passwords (password history = 5) but when I entered Password1 it was accepted.
Do you know where can be the problem ?
System info: Windows Server 2008 R2 (forest/domain level is also 2008)
Regards,
Marcin

This is very interesting. I don't have any lab to repro though... So I can't look at it closer.
From an LDAP perspective, when you change your password on AD, you have to comply with the password history policy. This requirement is send by the server to the client thanks to the supported control: LDAP_SERVER_POLICY_HINTS_OID that you can see just by
looking at the RootDSE of one of your DC (http://msdn.microsoft.com/en-us/library/cc223320.aspx Used with an LDAP operation to enforce password history policies during password set). I am
aware of issues with AD-LDS not honoring it, but not AD... I am not sure if the situation described with FIM here matches your issue:
http://support.microsoft.com/kb/2443871 in this article:
"The "Enforce password history" and "Minimum password age" Group Policy settings do not work when you reset the password for a Windows Server 2008 R2-based or a Windows Server 2008-based computer."
But it would mean that it also affects users not having a FGGP (because this isn't specific to FGGP), ad the minimum password age as well. If you have a chance to try this in a lab, let us now... In the mean time, if you can share logs or code from your
app? Like the section that does the password change?
Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

AD Reconciliation - Password Policy Error

all,
I am trying to run AD User Trusted recon. I am getting the following error for each user in AD.. I don't remember seeing this before on this system before and i have run recon successfully in the past. Is there any suggestion how to to go about debugging and fixing this issue?
<Jan 3, 2012 12:44:24 PM EST> <Error> <oracle.iam.platform.entitymgr.provider.ldap> <IAM-0042002> <An error occurred while creating the entity in LDAP, and the corresponding error is - javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 21 - LDAP Error 21 : [LDAP: error code 19 - Password Policy Error :9004: GSL_PWDNUMERIC_EXCP :Your Password must contain at least 1 numeric characters.
]]; remaining name 'cn=luten,cn=users,dc=xxxx,dc=org'>
thanks in advance,
Prasad

I doubt if you can do it now. I haven't worked on LDAPSync to tell you more, but the way I see it is that LDAPSync works with event handlers and since the users are already in, the ldap create event handlers might not trigger. Can you try just by modifying a user which is in OIM and not in LDAP and see if that creates the user in LDAP? If that works, then a simple program to do some dummy update on the user would work for you, if not that you will have to delete all those bad users and rerun the trusted recon by setting the XL.Reuseid = true. Be sure to drop the index on user table for re-using the userlogin.
-Bikash

Password policy through roles

Hi,
I have two password policies in my LDAP, mapped to the users through roles. One for active users and the other for inactive users. when i change the status from active to inactive, some times inactive password policy gets enabled, and some times it does not. The nsroles attribute in the user profile gets updated according to the role always, but the password policy subentry attribute is not getting updated sometimes.
Can Anyone help me on this.
Thanks in advance,
Navanidhi

This is probably a cache synchronization pb. Not something that I ever heard before though.
How quick do you check the password policy after changing the user status ?
Have you tried checking a minute or more after the change ?
Ludovic.

Unable to set Password Policy controls

When I call oracle.ldap.util.User.autheticateUser() I receive the exception "Unable to set Password Policy controls". What is the cause of this error? I was not able to find anything useful through google searches.
I am running everything inside ServiceMix. Furthermore, I am able to create a context and retrieve properties through oracle.ldap.util.User.getProperties().
Here is the stack trace:
my.company.Exception.AuthenticationException: Unable to set Password Policy controls
at my.company.OracleLdap.authenticateClient(OracleLdap.java:171)
at service.AuthenticationInInterceptor.isAuthenticated(AuthenticationInInterceptor.java:55)
at service.AuthenticationInInterceptor.handleMessage(AuthenticationInInterceptor.java:32)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111)
at org.apache.cxf.transport.http_osgi.OsgiDestination.doMessage(OsgiDestination.java:80)
at org.apache.cxf.transport.http_osgi.OsgiServletController.invokeDestination(OsgiServletController.java:321)
at org.apache.cxf.transport.http_osgi.OsgiServletController.invoke(OsgiServletController.java:107)
at org.apache.cxf.transport.http_osgi.OsgiServlet.invoke(OsgiServlet.java:53)
at org.apache.cxf.transport.http_osgi.SpringOsgiServlet.invoke(SpringOsgiServlet.java:48)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.handle(HttpServiceContext.java:111)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:68)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: oracle.ldap.util.UtilException: Unable to set Password Policy controls
at oracle.ldap.util.User.authenticateUser(User.java:1243)
at my.company.OracleLdap.authenticateClient(OracleLdap.java:158)
... 29 more
Edited by: user1094798 on Feb 22, 2011 12:53 PM
Edited by: user1094798 on Feb 22, 2011 12:55 PM
Edited by: user1094798 on Feb 22, 2011 1:17 PM

I fixed it by changing the way my InitialDirContext is created.
Previously I was using:
InitialDirContext ctx = oracle.ldap.util.jndi.ConnectionUtil.getDefaultDirCtx(hostname, portNum, adminName, adminPass);
Now I'm using:
Hashtable env = new HashTable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://" + hostname + ":" + portNum);
env.put(Context.SECURITY_PRINCIPAL, adminName);
env.put(Context.SECURITY_CREDENTIALS, adminPass);
InitialDirContext ctx = new InitialDirContext(env);
Edited by: user1094798 on Feb 23, 2011 8:29 AM

DSEE 6.3.1 password policy issue

We're rolling out a network wide password policy on both our LDAP and AD environments. The two are synchronized using Identity Synchronization for Windows 6.0. Today, in my test environment I enabled the password policies that we plan to implement. Since we never had any 5.x directory servers, I set the password policy mode to be Directory Server 6 mode. After configuring everything I tried changing a users password in the AD domain and ISW picked up the change however the following error showed up in the ISW audit log:
[16/Feb/2011:16:56:03.957 -0500] FINE 18 CNN100 beer-ds01 "LDAP operation on entry uid=tuser,ou=people,dc=beer,dc=com failed at ldaps://beer-ds01.lab.endeca.com:636, error(53): LDAP server is unwilling to perform ((Password Policy: modify policy entry) "objectClass=passwordPolicy" is not supported in pwdCompat:4 (DS6-mode).)." (Action ID=CNN101-12E30785AA8-1, SN=7)When I then tried the same password change directly against the directory server using ldapmodify, I saw the same error:
# ldapmodify -D 'cn=directory manager' -w endeca123
dn: uid=tuser,ou=people,dc=beer,dc=com
changetype: modify
replace: userpassword
userpassword: !changem3!
modifying entry uid=tuser,ou=people,dc=beer,dc=com
ldap_modify: DSA is unwilling to perform
ldap_modify: additional info: (Password Policy: modify policy entry) "objectClass=passwordPolicy" is not supported in pwdCompat:4 (DS6-mode).The password policy is:
version: 1
dn: cn=Password Policy,cn=config
objectClass: top
objectClass: ldapsubentry
objectClass: pwdPolicy
objectClass: sunPwdPolicy
cn: Password Policy
pwdAttribute: userPassword
passwordStorageScheme: CRYPT
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
passwordRootdnMayBypassModsChecks: off
pwdInHistory: 10
pwdMinAge: 86400
pwdCheckQuality: 2
pwdMinLength: 6
pwdMustChange: FALSE
pwdMaxAge: 15552000
pwdExpireWarning: 86400
pwdGraceAuthNLimit: 0
pwdKeepLastAuthTime: FALSE
pwdLockout: TRUE
pwdMaxFailure: 5
pwdFailureCountInterval: 1800
pwdIsLockoutPrioritized: TRUE
pwdLockoutDuration: 1800I'm at a complete loss as to what causing this problem and am not sure what steps to take to figure out how to fix it. Can anyone offer some help?

It turns out that when I setup the ISW install I, for a reason that now I cannot comprehend nor remember, added the passwordPolicy objectclass to the auxillary objectclasses used when created a new user. Since that objectclass is a 5.x objectclass my problems started when I moved to pwd-compat DS6-mode. I was able to restore my test systems from a backup, remove the objectclass from the ISW config and then proceed with the password policy rollout which worked fine this time around. Thanks for the suggestions and help.

Sun LDAP & Password

Hi im just wondering about how password are stored in sun ldap.
Now when I view a users password in the console it is encrypted, when i change the password it also gets encrypted which is fine.
Now my question is for example if I am querying or adding new entries in LDAP from a vb.net script can I
1) Compare a password entered by the user on my homepage to the encrypted password in ldap
2) If i had a new entry with password from a .net page does this automatically get encrypted ?
Thanks in advance

Hi Jeremy,
here the answers to your questions:
>My question is which system takes precedence over the password policy?
Unfortunately there is no policy verification between the portal and your Sun One LDAP. So if you reset the password from the portal then only the portal password policies can be checked.
> If I wanted to do password resets from the Portal, does the portal then store only the password in its database?
No, the password will be stored in the LDAP, but only if it also corresponds with the LDAP policies. If not, then you will get an error, but you will not see the real LDAP exception.
> Also what would then happen if you tried to reset the password from the LDAP?
The password in the LDAP does not have to fit to the Portal password policies. When you log in, the portal will only check if the password you tipped in is the new one in LDAP and will not check any policies.
Hope this brings some light in,
Robert

LDAP Password Policy - Syntax

Similar Messages

Maybe you are looking for