A couple of things I have noticed. I am not able to access the authenticator, my custom interceptor extends AuthenticationInterceptor which has a collection of authenticators but that collection is private. The other thing I have noticed is that if the user account in question is already cached then my custom bind event is never called, so changes made here would have no impact. Thoughts?
Log messages from first login: [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Intercepting bind operation [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Executing parent level bind events first [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Executing custom bind event [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Attempting to validate status attribute for uId use...@place.com [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Status for use...@place.com is active [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Attempting to validate pwdReset attribute for uId use...@place.com [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - pwdReset for use...@place.com is false [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Attempting to set lastLogon attribute for uId use...@place.com [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - lastLogon should be set now [16:31:55] INFO [com.cga.aaims.ldap.apacheds.interceptor.AAIMSAuthenticationInterceptor] - Done with custom bind action, calling next operation [16:31:55] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:31:55] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:31:55] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:31:55] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored Log messages from second login: [16:32:12] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:32:12] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:32:12] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored [16:32:12] WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] - Requested attribute pwdLastSet does not exist in the schema, it will be ignored Thanks, Justin Isenhour | Lead Developer, Systems and Technology Group | Compass Group USA | 2400 Yorkmont Road | Charlotte, NC 28217 | 704.328.5804 | justin.isenh...@compass-usa.com -----Original Message----- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Thursday, December 7, 2017 1:52 PM To: users@directory.apache.org Subject: Re: [Ext] Re: [ApacheDS] How to clear cached authentication on change of custom attribute Le 06/12/2017 à 16:53, Isenhour, Justin a écrit : > My desire was to keep all standard features of the default authenticator, > allow it to run first to perform the standard validations then run my custom > validation after. To do this I created my custom authentication interceptor > which extends AuthenticationInterceptor, then I updated the list of > interceptors and changed the class name for the AuthenticationInterceptor > from the standard class to my custom class. Attached is the source code for > my custom authenticator. For now I will try to move the call to super just > after I perform my status check and see if that works but if you have a > better solution I would be happy to hear it. If you have any other feedback > on this custom authenticator (problems I may be causing for myself that I am > not aware of) please let me know as well. I guess that calling authenticator.invalidateCache( bindContext.getDn() ); *before* calling super.bind(bindContext) should do the trick. The idea is to remove the DN from the cache, so that the bind operation is processed fully, instead of being bypassed if the user has already been bound. From the performance point of view, the impact is not necessarily critical, if you don't have thousand bind/s anyway. Give it a try, and let me know if it does the job. -- Emmanuel Lecharny Symas.com directory.apache.org
