No that package is not installed.
Would installning it break anything in the current setup, you think?

It shouldn't be installed if you're not using it but if you did have it installed that could explain why. I wrote about something similar

https://world.optimizely.com/blogs/scott-reed/dates/2018/11/working-around-iqueryablenotificationusers-when-using-external-claims-based-cms-users/

And in the comments someone said that support had told them to make sure the package was removed. But essentially as was as I'm aware you want to make sure that whatever implementation IQueryableNotificationUsers is using is correct for Active Directory. I was hoping if you had this package installed that the fallback after removing it would default to the correct one.

I believe the default is to use DefaultSynchronizedUsersRepository but I'm not sure if the Active Directory membership provider syncs users in the DB like the others, I would probably assume not.

Thanks for your input. I have ensured that package is not installed.

Have you checked in the code what IQueryableNotificationUsers implementation it's using? You could inject it and see what the method returns as this is used in the areas for user search. If there's not an implementation of this for ADMP it's only one method so you should be able to create one easily.

I cannot find any implementation of IQueryableNotificationUsers in the solution.
And not able to test it against the working AD since its behind a firewall.

One other thing I notice was what i Cms/Admin Search Users only users within SqlServerMembershipProvider is listed, but no from SqlServerMembershipProvider.
Ergo same results as in Content Approval. Groups are, however listed. I guess that is expected.

In app-settings I have a query for Roles.


Is there a equilent setting for users?

Yes as mentioned any user search will use the IQueryableNotificationUsers interface, that's usually both the admin area and the content approvals in my experience. I wouldn't have expected IQueryableNotificationUsers you to have an instance of it in your solution it will be using an implementation in the Optimizely DLLs which as mentioned I think will be DefaultSynchronizedUsersRepository.

The DefaultSynchronizedUsersRepository syncs users from the claims information (email, name and surname) when a user logs in, so that user will also only be available in the search once that user has logged in via the authentication system. The IQueryableNotificationUsers.FindAsync looks in the claims database. I don't think off the top of my head using the ActiveDirectoryMembershipProvider will expose as claims but I could be wrong, although as mentioned only users who have logged in normally will come through so make sure when checking you're aware of that and to only check for users who have logged in.

Usually what happens for example when you install the asp.net identity package is there's a version of the IQueryableNotificationUsers that overrides the default one and supports querying for users based on the underlying provider. This is why I had asked you to check if you had the package installed. As your using the Microsoft ActiveDirectoryMembershipProvider if the claims way of loading isn't going to work for this provider you'll need one that supports it. I did search in the nuget package library but couldn't find anything.

So at worst you'll have to create a class that implements IQueryableNotificationUsers.FindAsync against the ActiveDirectoryMembershipProvider search methods

Also not sure what "In app-settings I have a query for Roles." is. What app setting is this?

Sorry, I wrote it in previous post, but it was omitted

The key is "ActiveDirectoryRoleProvider.GetAllRolesQuery" and its value is search filter, I guess.

In my debugging, I have come across that its throwing the error "An invalid dn syntax has been specified", so there is a comma character in a group's distingguishedName and in the flow, that comma is being escaped twice.

Now I have ActiveDirectoryRoleProvider extracted and implemented some own methods.

hoping soon this is resolved. Thanks for your answers

Bumping this up, now when I have sat down a little more.
I've manage to connect to the AD. I can log in with my AD user which has admin access.
In Cms Admin i can search and browse AD users.
In Content Approval, when setting up, only users in [tblSynchedUser] is searchable. Is this how it is supposed to be or rather direct search like the Search Users/Groups seem to work?
If it is supposed to search in SyncedUser Table, how is the actual syncronization is made; so all users/roles are syncronized?