Resolving AD-groups by displayName

Sep 11, 2013 at 6:45 AM
Hello,

is where any possibility to relove AD-groups by AD-displayName and associate the response with the claim type http://schemas.microsoft.com/ws/2008/06/identity/claims/role and the value sAMAccountName? I have tried to link the "AccountName" over the LDAP Attribute name "displayName" and the LDAP Object class "group" in Claim list. So i can search the AD-Groups by their displayName, but the result can't be created in SharePoint.

Cheers Frank
Coordinator
Sep 12, 2013 at 12:48 PM
hello Frank,
this is not possible in the current version but this is something I can consider (as a generic feature) for a future release.
cheers,
Yvan
Sep 13, 2013 at 10:35 AM
Hello Yvan,

this would be creat :-) We are needing thie feature.

Thanks Frank
Coordinator
Sep 17, 2013 at 3:57 PM
hello Frank,
for your information, I implemented the feature you requested in an update (that includes additional improvements) and I'm currently testing it, I hope to publish the update next week.
But in this update, the feature will require some code to be implemented, so it will be for developers only (using the developers package).
I'm planning to integrate this feature directly in the LDAPCP admin pages but that will take more time to implement.
cheers,
Yvan
Sep 19, 2013 at 8:06 AM
Hello Yvan,

i will test it when the update is released for developers next week.

Thank you
Frank
Coordinator
Sep 23, 2013 at 11:08 AM
hello Frank,
the update is released now, please let me know if it fits your needs.
cheers,
Yvan
Sep 23, 2013 at 11:50 AM
Hello Yvan,

i'll test it next week an give you response.

cheers Frank
Oct 10, 2013 at 1:36 PM
Edited Oct 11, 2013 at 8:14 AM
Hi Yvan,

i have tested the normal package with no success. The developers package i can't compile. Can you send me a compiled package?

cheers Frank
Coordinator
Oct 11, 2013 at 11:33 AM
hello Frank,
to implement the feature you need to use the developer package, but you also need to customize the sample to fit your needs.
The solution should definitely compile, I use Visual Studio 2012 Update 3, maybe you need to update Visual Studio too.
What error do you get when you compile?
cheers,
Yvan
Nov 8, 2013 at 9:18 PM
Hi Yvan,

First of all thanks for the great solution ...

I'm having a similar requirement but in my case I'm getting the full DN for (Groups only) from the Identity Provider, which dosen't look nice on the search results. I got the developer code and I'm wondering were should I make a modification to clean the result on the distinguishedName ( CN=dfddf,OU=sdsdsds,OU=sdsdsd,DC=dssdsd) and extract only the CN part ...

Thanks,
Sam
Coordinator
Nov 12, 2013 at 10:52 AM
hello Sam,
you should not query the distinguishedName attribute, query the sAMAccountName attribute instead that should contain only the group name (the CN), which is exactly what you want.
cheers,
Yvan
Nov 12, 2013 at 8:52 PM
Thanks for clarifying this... It finally resolved properly on the People Picker.

But now when I grant a group permissions to a site it doesn't apply the permissions to users under that group. I tested the same groups on another environment where I use only NTLM and it worked fine. Not sure what did I miss?
Coordinator
Nov 13, 2013 at 11:36 AM
hello,
that must be a difference between how SharePoint receives the group from the external STS, and how the permission is defined.
For example you define a permission on "groupname", but external STS sends "domain\groupname"
If so, the easiest way to fix this is to make the change on the external STS so that groups are formatted correctly
cheers,
Yvan
Jan 31, 2014 at 7:33 AM
Hi Yvan,

now we had time to compile our own Solution. The Problem is, that the displayname for a group is only displayed in the Peaple Picker when i set in the mapping no 5 ResolveAsIdentityClaim to "true"

1.) new AttributeHelper{LDAPAttributeName="sAMAccountName", LDAPObjectClass="user", claimType=nsmsclaims.ClaimTypes.WindowsAccountName, claimEntityType = SPClaimEntityTypes.User, peopleEditorEntityDataKey=PeopleEditorEntityDataKeys.AccountName, LDAPAttributeToDisplay="displayName"},
2.) new AttributeHelper{LDAPAttributeName="displayName", LDAPObjectClass="user", ResolveAsIdentityClaim=true, peopleEditorEntityDataKey=PeopleEditorEntityDataKeys.DisplayName},
3.) new AttributeHelper{LDAPAttributeName="mail", LDAPObjectClass="user", ResolveAsIdentityClaim=true, peopleEditorEntityDataKey=PeopleEditorEntityDataKeys.Email},
4.) new AttributeHelper{LDAPAttributeName="sAMAccountName", LDAPObjectClass="group", claimType=nsmsclaims.ClaimTypes.Role, claimEntityType = SPClaimEntityTypes.FormsRole, peopleEditorEntityDataKey=PeopleEditorEntityDataKeys.AccountName, LDAPAttributeToDisplay="displayName"},
5.) new AttributeHelper{LDAPAttributeName="displayName", LDAPObjectClass="group", ResolveAsIdentityClaim=true, peopleEditorEntityDataKey=PeopleEditorEntityDataKeys.DisplayName},

The mappings 1 to 4 are working, but mapping 5 gives an error that the user could not resolved. The cause of the error is the linking to the identityclaim - that's clear.

Can you please help me to define am mapping that resolves a displayname of a group to the sAMAccountName of a group and put this to the permission for the role?

Thank you
Frank
Jul 10, 2014 at 1:09 PM
Hi,

I am thinking that this is still an open issue looking at the samples and code. I cannot figure out a way to use the samples to resolve a group to its sAMAccountName based on a search that matches its displayName. This is problematic for my current project since the groups have cryptic sAMAccountNames (e.g. grp22341) and display names that make sense to the users (e.g. "IT Staff"). So we really need a way to search on display name while resolving to the sAMAccountName for the authorization claim which is returned as a role claim for the user. We don't have any guarantee that the display name is unique so we need to use the sAMAccountName.

I think a useful update to this code base might be a setting that allows us to say "search on both ldap attribute and display ldap attribute" to map to the corresponding claim (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role). So in this example, the ldap search filter would include "(|(&(objectclass=group)(sAMAccountName=IT*))(&(objectclass=group)(displayName=IT*))". This will seem intuitive for users since then what they see displayed as matches will contain the string they entered.

thanks,
Mary
Coordinator
Jul 10, 2014 at 3:17 PM
hello Mary,

indeed, I realize now that I totally misunderstood the need, sorry for that.
What changed is the possibility to specify an attribute to display different than the attribute to query, but this is now your need.

Your need is to have an attribute to query different than the attribute used to create the value of the permission, for groups.
This feature already exists for identity claim, but it's definitely not possible for groups.

I will take a look at this but at 1st sight there is quite some work to implement this, and to be honest it's not in my top priority list...
I'll update this thread if I finally implement it

cheers,
Yvan
Jul 28, 2015 at 3:46 AM
Yvand, any update on whether "Resolving AD-groups by displayName" is on the roadmap?

Thanks
Coordinator
Sep 1, 2015 at 2:33 PM
Edited Sep 1, 2015 at 2:34 PM
Hello,
sorry for the very late reply, but yes, this option was added in v3.6 (published in January 14)

Below is a sample that shows how to configure this (to add in SetCustomConfiguration method):
this.CurrentConfiguration.AttributesListProp = new List<AttributeHelper>
{
    // other claim types
    [...]
    
    // Define group claim type: permission is created on LDAP attribute sAMAccountName but lookup is made on LDAP attributes sAMAccountName and displayName
    new AttributeHelper{LDAPAttribute="sAMAccountName", LDAPObjectClassProp="group", ClaimType=WIF.ClaimTypes.Role, ClaimEntityType = SPClaimEntityTypes.FormsRole},
    new AttributeHelper{LDAPAttribute="displayName", LDAPObjectClassProp="group", ClaimType=WIF.ClaimTypes.Role, ClaimEntityType = SPClaimEntityTypes.FormsRole, CreateAsIdentityClaim=true},
}
thanks,
Yvan