Interesting requirement.... Can you please share your Cache Refresh configs? I would love to test this scenario in my local environment.

is there a way to export the configuration to provide it to you ?

If AD has an access log, it would be interesting to see what the filter shows on the server side. This is not a typical LDAP filter where `attribute=value`, which is not to say it's not a valid filter. But keep in mind that cache refresh is a pretty basic synchronization service.

ok so is there a specific way to sychronize only active enabled users?

1. I would check AD to see what the filter looks like. It may be possible. 3. Is there an attribute called "status" ?

Thats why I linked the article from microsoft in regards to the filter. That is the exact syntax for an LDAP filter to filter all objects that are specified in the microsoft support article regarding ldap filters. I have used that filter or something close for: AD powershell, Apache and PHP. I'm not sure what is causing the issue AD does have an "Enabled" property with a boolean value. but I do not believe that is a property you can compare in an actual LDAP filter. so i can use the following filter to filter by persons, users, that have a given and and have a surname and are enabled. When i disable the user the filter removes that user from the next query. ``` PS C:\Users\Administrator> $ldapfilter = "(&(objectCategory=person)(objectClass=user)(givenName=*)(sn=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" PS C:\Users\Administrator> get-aduser -LDAPFilter $ldapfilter DistinguishedName : CN=jmcnab_vacuus.biz,OU=vacuus.biz,OU=SolidCP,DC=uat,DC=securence Enabled : True GivenName : Jeremy Name : jmcnab_vacuus.biz ObjectClass : user ObjectGUID : 2e10f920-b483-4a0c-805e-2af005b3d443 SamAccountName : jmcnab_vacuus.biz SID : S-1-5-21-1307436397-1106884597-2991200824-1166 Surname : McNab UserPrincipalName : jmcnab@vacuus.biz DistinguishedName : CN=jessmcnab_sagarpg.or,OU=sagarpg.org,OU=SolidCP,DC=uat,DC=securence Enabled : True GivenName : jess Name : jessmcnab_sagarpg.or ObjectClass : user ObjectGUID : 5f0632f8-1791-4c41-a253-38a5099a8dbc SamAccountName : jessmcnab_sagarpg.or SID : S-1-5-21-1307436397-1106884597-2991200824-1165 Surname : mcnab UserPrincipalName : jessmcnab@sagarpg.org PS C:\Users\Administrator> get-aduser jmcnab_vacuus.biz DistinguishedName : CN=jmcnab_vacuus.biz,OU=vacuus.biz,OU=SolidCP,DC=uat,DC=securence Enabled : True GivenName : Jeremy Name : jmcnab_vacuus.biz ObjectClass : user ObjectGUID : 2e10f920-b483-4a0c-805e-2af005b3d443 SamAccountName : jmcnab_vacuus.biz SID : S-1-5-21-1307436397-1106884597-2991200824-1166 Surname : McNab UserPrincipalName : jmcnab@vacuus.biz PS C:\Users\Administrator> get-aduser jmcnab_vacuus.biz | set-aduser -Enabled $false PS C:\Users\Administrator> get-aduser -LDAPFilter $ldapfilter DistinguishedName : CN=jessmcnab_sagarpg.or,OU=sagarpg.org,OU=SolidCP,DC=uat,DC=securence Enabled : True GivenName : jess Name : jessmcnab_sagarpg.or ObjectClass : user ObjectGUID : 5f0632f8-1791-4c41-a253-38a5099a8dbc SamAccountName : jessmcnab_sagarpg.or SID : S-1-5-21-1307436397-1106884597-2991200824-1165 Surname : mcnab UserPrincipalName : jessmcnab@sagarpg.org ```

Use ldapsearch from the gluu server to check if the ldap filter "(enabled=True)" works. ``` # cd /opt/opendj/bin # ldapsearch -h ad-hostname -p 636 -D "ad bind dn" -j ~/.pw -Z -X \ -b "CN=jmcnab_vacuus.biz,OU=vacuus.biz,OU=SolidCP,DC=uat,DC=securence" \ "Enabled=True" ``` If the entry comes back, you're in business. Try "Enabled=False" too and make sure nothing comes back.

nope but this does before enabling user ``` root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" '(&(objectCategory=person)(objectClass=user)(givenName=*)(sn=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' dn givenname mail dn: CN=jessmcnab_sagarpg.or,OU=sagarpg.org,OU=SolidCP,DC=uat,DC=securence givenName: jess mail: jessmcnab@sagarpg.org ``` after ``` root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" '(&(objectCategory=person)(objectClass=user)(givenName=*)(sn=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' dn givenname mail dn: CN=jmcnab_vacuus.biz,OU=vacuus.biz,OU=SolidCP,DC=uat,DC=securence givenName: Jeremy mail: jmcnab@vacuus.biz dn: CN=jessmcnab_sagarpg.or,OU=sagarpg.org,OU=SolidCP,DC=uat,DC=securence givenName: jess mail: jessmcnab@sagarpg.org ``` with just the enabled ``` root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" '(&(enabled=True))' dn givenname mail root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" 'enabled=True' dn givenname mail root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" 'Enabled=True' dn givenname mail root@exgluu:~# ldapsearch -h uatex05 -p 636 -D "CN=gluu,CN=Users,DC=uat,DC=securence" -j ~/.adpw -Z -X -b "OU=SolidCP,DC=uat,DC=securence" 'Enabled=False' dn givenname mail root@exgluu:~# ``` I'm not proficient with java per se but it looks like the LDAP filter feature is trying to interpret the LDAP filter and not taking it as a literal string for the filter itself.

any ideas ?

So 'enabled` is not searchable.... too bad. BTW, in LDAP, attribute names are not case sensitive. Most string values are also indexed as case insensitive. RDBMS is the opposite of course. Ok, one more idea... ``` (userAccountControl:1.2.840.113556.1.4.803:=2) ``` Try entering this in section called `Custom LDAP filter`. I think this will work... it should append this filter.

I'm pretty sure I did try that. I will provide the logs regarding this. but that ldap filter would only return disabled users not enabled users.

Yeah its a similar result. ``` 2021-06-28 15:57:00,622 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1158) - Created Cache Refresh PersistenceEntryManager: org.gluu.persist.ldap.impl.LdapEntryManager@7f58b641 2021-06-28 15:57:00,623 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:339) - Attempting to load entries from source server 2021-06-28 15:57:00,625 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:348) - Found '4' entries in source server 2021-06-28 15:57:00,626 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:352) - Found '4' unique entries in source server 2021-06-28 15:57:00,626 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:404) - Found '0' changed entries 2021-06-28 15:57:00,626 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:409) - Loaded '0' problem entries from problem file 2021-06-28 15:57:00,679 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:423) - Updated '0' entries 2021-06-28 15:57:00,679 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:425) - Failed to update '0' entries 2021-06-28 15:57:00,679 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:468) - Removed '0' persons from target server 2021-06-28 15:57:00,679 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:485) - There are '4' entries before updating inum list 2021-06-28 15:57:00,679 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:489) - There are '4' entries after removal '0' entries 2021-06-28 15:57:00,680 INFO [ForkJoinPool.commonPool-worker-7] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:493) - There are '4' entries after adding '0' entries 2021-06-28 15:59:00,640 INFO [ForkJoinPool.commonPool-worker-5] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1158) - Created Cache Refresh PersistenceEntryManager: org.gluu.persist.ldap.impl.LdapEntryManager@493c43b7 2021-06-28 15:59:00,640 INFO [ForkJoinPool.commonPool-worker-5] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:339) - Attempting to load entries from source server 2021-06-28 15:59:00,644 ERROR [ForkJoinPool.commonPool-worker-5] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:205) - Exception happened while executing cache refresh synchronization org.gluu.persist.exception.operation.SearchException: Unknown filter type '-87' at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilterImpl(LdapFilterConverter.java:144) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilter(LdapFilterConverter.java:94) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter$Proxy$_$$_WeldClientProxy.convertRawLdapFilterToFilter(Unknown Source) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshService.createFilter(CacheRefreshService.java:62) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.loadSourceServerEntriesWithoutLimits(CacheRefreshTimer.java:859) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.detectChangedEntries(CacheRefreshTimer.java:345) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:301) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processInt(CacheRefreshTimer.java:200) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.processInt(Unknown Source) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:184) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.process$$super(Unknown Source) [classes/:?] at jdk.internal.reflect.GeneratedMethodAccessor491.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.gluu.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-4.2.3.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) [?:?] at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692) [?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) [?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) [?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) [?:?] ```

Oh, ok. My mistake. Then try ``` (!(userAccountControl:1.2.840.113556.1.4.803:=2)) ```

results ``` 2021-06-28 16:09:00,622 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1158) - Created Cache Refresh PersistenceEntryManager: org.gluu.persist.ldap.impl.LdapEntryManager@4ed39911 2021-06-28 16:09:00,622 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:339) - Attempting to load entries from source server 2021-06-28 16:09:00,624 ERROR [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:205) - Exception happened while executing cache refresh synchronization java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilterImpl(LdapFilterConverter.java:110) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilter(LdapFilterConverter.java:94) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter$Proxy$_$$_WeldClientProxy.convertRawLdapFilterToFilter(Unknown Source) ~[oxcore-persistence-ldap-4.2.3.Final.jar:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshService.createFilter(CacheRefreshService.java:62) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.loadSourceServerEntriesWithoutLimits(CacheRefreshTimer.java:859) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.detectChangedEntries(CacheRefreshTimer.java:345) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:301) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processInt(CacheRefreshTimer.java:200) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.processInt(Unknown Source) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:184) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.process$$super(Unknown Source) [classes/:?] at jdk.internal.reflect.GeneratedMethodAccessor491.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.gluu.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-4.2.3.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) [?:?] at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692) [?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) [?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) [?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) [?:?] ```

Ok, so that's where we started this ticket. I think it's possible, but we may need to push an enhancement to oxTrust. I think you can't send controls like this via *ad. hoc* filters. The ldap library is escaping the content. If you were supported we could push a fix.

This seems like a bug, not a feature request. The feature name is 'Custom LDAP filter', but it does not accept a custom ldap filter... We are still evaluating and testing scenarios before we commit to any support contract. I'm surprised that i'm the first person who has brought this up. I would think when syncing identities from an active directory server that the conversation regarding enabled vs disabled would have come up by now.

It's not a bug because we are validating this input based on standard attribute syntax, like (&(c=us)(status=active)). This is a very geeky ldap filter... It is common to filter on active accounts, but normally there is a filter like `status=active`.

Let me make sure I am correct in my interpretation of what you are telling me. It is currently **NOT** possible out the box to use your products cache refresh configuration which is required for authentication, based on my understanding of the cache refresh/authentication settings, against a Microsoft Active Directory server and filter by enabled or disabled accounts. And, it is your assertion that this is not a bug. Additionally, if I want your product to do that, I have to pay you first?

thanks will look elsewhere

You can sync AD for active users as long as the status attribute is rendered as a string, and not some special control. Cache Refresh is one of the oldest features in the Gluu Server. In 11 years, no one has asked for this. So yes we can support this special filter, but no, we're not going to prioritize this enhancement on a community support request.