Groups/roles are only imported after a user has logged in that have them I think. Try log in a user that have the groups you are missing and they will likely show up so you can set access rights in admin etc
I had this problem. Or atleast I think it might be the same. However I did pinpoint which OU to use. I think the ActiveDirectoryProviders only search one OU and if you have several on the same level as I did, you need to have several connections. That was my conclusion atleast. I am no expert on AD's!
We had 2 OUs that needed to be included as groups and users in our episerver environment.
First one was the internal groups and users for the company, and the second was external users (like consults).
In order for me to get all the users from the external OU and all users from the internal OU I had to create 2 connections to the AD pinpointing the diffrent OU's.
This meant I had to create my own Multiplexing provider that was able to have as many providers as I wanted.
I ended up with a role and membershipprovider that looked similar to this;
<add name="CustomMultiplexRoleProvider" applicationName="/" type="Company.NameSpace.CustomMultiplexRoleProvider, Company.NameSpace" provider1="WindowsRoleProvider" provider2="CustomAdRoleProvider", provider3="CustomAdRoleProvider" providerMap1="WindowsMembershipProvider" providerMap2="CustomAdMembershipProvider", providerMap3="CustomAdMembershipProvider" />
<add name="CustomMultiplexMembershipProvider" ........ />
with Ldap connections like these;
So what this solution did was checking for users and roles in WindowsProvider, then CustomADProvider 1 (Internal OU) and finally CustomADProviders 2 (External OU)
Might be an easier solution but this worked perfectly for me.
@Daniel - I don't think that's the case here. It's a Relate site and when I view a user's profile (in Community) then some of the groups missing from the set access rights screen are available when searching for all available groups. So it's almost as if CMS and Community are pulling different results back from the AD.
@Jens - That sounds like a good solution and something I'll keep in mind. What puzzles me is that the LDAP connection string is not targeting a specific OU, only the domain is specified so I'd expect all the groups to be returned.
I think that the ActiveDirectoryProvider will only search one OU and everything below that ou. If you have several OU on same level as I did. It will only use one of them. I might be wrong, but I think someone told me that it works like that.
Don't you specify in config what roles to transfer to the Relate user? I think you do, unless they changed that?
<episerver.common> <integration> <rolesToSynchronize> <add name="*" /> </rolesToSynchronize> <rolesToTransfer> <add name="..." /> </rolesToTransfer> </integration>
<add name="EPiServerCommonUserIntegration" type="EPiServer.Common.Web.Authorization.IntegrationHttpModule, EPiServer.Common.Web.Authorization" preCondition="managedHandler" />
I've been trying to get multiplexing working with no success so far. Our scenario is slightly different in that one OU contains groups and another OU contains users. I'm getting an error when pointing to each of these OUs when calling ActiveDirectoryMembershipProvider.GetUser which I believe is caused as the groups that the user belong to are in a different OU to the user (even though we're specifiying the groups OU in the provider via multiplexing).
Do you know if it's possible to do this? I'm guessing your scenario was two different OUs that contained users and groups which is why it works for you?
Now this may or may not be an EPiServer thing but I thought I'd see if anyone had encountered this anyway.
We have a site that users AD role and membership providers for authentication and user management and the connection string for this is set to the domain only (no DN, OU etc) i.e. "LDAP://domain.com". The user account that is specified in web.config to connect to the AD is a read only user.
In our copy of the site, when we navigate to "Set Access Rights" in Admin mode, select "Add Users/Groups" and then search for all groups we get all the groups that are available in the AD (and we get the same if we use the "Search User/Group" function in Admin mode as well).
On our client's site it is setup exactly the same (obviously LDAP domain and user are different) and they are only seeing a subset of the groups available in their AD and it seems to be all groups from one OU. We suspected a permissions issue and they have tested using a domain admin account in the role/membership provider and still only see groups from this one OU.
Has anyone else seen this and know how to troubleshoot and fix?
Thanks in advance,