Active Directory groups are not being added after resolving in Peoplepicker - SharePoint Enterprise 2013

Sep 18, 2014 at 4:07 PM
Active Directory groups are not be added after resolving in peoplepicker. Our enviornment is configured with ping federated without ups.

We have configured LDAPCP.codeplex.com integrating with Ping federated. please find the claim mapping, we configured in our environment.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname givenName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname cn user Edit DeleteSave Cancel
Used as metadata for the permission created title user DeleteSave Cancel
Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user DeleteSave Cancel
Used as metadata for the permission created telephoneNumber user DeleteSave Cancel
Used as metadata for the permission created mail user DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname displayName User Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname mail User Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname DisplayName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname Group-Membership-SAM group Edit DeleteSave Cancel

That's the identity claim type (Account Name) defined in the trust "PingFederateSTS5" associated with LDAPCP. It should always be present, unique and modified with care.

we are getting following transaction errors from SharePoint ULS logs.
[LDAPCP] this LDAP query did not return any result result: "(|(&(objectclass=user) (sAMAccountName=global-sp-gsdm-s-g)))" and message "The user doesn't exist or no unique user"
Coordinator
Sep 19, 2014 at 11:41 AM
Hello, claim types must be unique, you should not create multiple entries with same claim type (in your case http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname).
Clean your list to not have duplicate claim types, then you may have to recreate some permissions (created with incorrect claim type) to completely resolve all issues.
Cheers,
Yvan
Sep 20, 2014 at 3:29 AM
Hi Yvand, Thanks for your quick response.

As per your suggestion, we have removed the below claim mapping from the environment.
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname displayName User Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname mail User Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname DisplayName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname Group-Membership-SAM group Edit DeleteSave Cancel

Currently the claim mapping as below:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname givenName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname cn user Edit DeleteSave Cancel
Used as metadata for the permission created title user DeleteSave Cancel
Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user DeleteSave Cancel
Used as metadata for the permission created telephoneNumber user DeleteSave Cancel
Used as metadata for the permission created mail user DeleteSave Cancel


Please let us know, other required claim mapping required for Users and AD groups.
Coordinator
Sep 23, 2014 at 11:08 AM
hello,
yes now it looks much better. Does the claim type "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" appears in green in the page?
If yes then it's all set, otherwise that means this claim type is missing in the SPTrustedIdentityTokenIssuer "PingFederateSTS5" and you need to add it.
cheers,
Yvan
Sep 25, 2014 at 5:13 PM
Hi Yvand,

Thanks for the response, we have added claim type "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to SPTrustedIdentityTokenIssuer "PingFederateSTS5".
In the earlier Post, you have specified the claim type will be GREEN__"Do you mean that claim type will become green, as we are not seeing any green color in the page"__.

Current Claim Mapping:
Claim type LDAP attribute LDAP object class Actions
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname givenName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname cn user Edit DeleteSave Cancel
Used as metadata for the permission created title user DeleteSave Cancel
Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user DeleteSave Cancel
Used as metadata for the permission created telephoneNumber user DeleteSave Cancel
Used as metadata for the permission created mail user DeleteSave Cancel
linked to identity claim displayName user DeleteSave Cancel
linked to identity claim mail user DeleteSave Cancel
linked to identity claim sAMAccountName group DeleteSave Cancel
linked to identity claim displayName group DeleteSave Cancel

That's the identity claim type (Account Name) defined in the trust "PingFederateSTS5" associated with LDAPCP. It should always be present, unique and modified with care.

we have added the below lines to resolve Group in peoplepicker before that we received error in resolve the group.
linked to identity claim sAMAccountName group DeleteSave Cancel
linked to identity claim displayName group DeleteSave Cancel

While resolving the group, we found that below sequence from ULS logs.
  1. [LDAPCP] The LDAP Query "(|(&(objectclass=user) (sAMAccountName=GLOBAL-SP-GSDM-S-G))(&(objectclass=user) (cn=GLOBAL-SP-GSDM-S-G))(&(objectclass=user) (displayName=GLOBAL-SP-GSDM-S-G))(&(objectclass=user) (mail=GLOBAL-SP-GSDM-S-G))(&(objectclass=group) (sAMAccountName=GLOBAL-SP-GSDM-S-G))(&(objectclass=group) (displayName=GLOBAL-SP-GSDM-S-G)))" returned 1 result(s)
  2. LDAPCP] Created permission with claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" to the list of results.
  3. [LDAPCP] Added permission created with LDAP lookup: claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"
We received the same error when tried to add group after resolving from peoplepicker
[LDAPCP] this LDAP query did not return any result result: "(|(&(objectclass=user) (sAMAccountName=global-sp-gsdm-s-g)))" - User doesn't exist or no unique user.


PowerShell Output of Pingfederated Configuration as below:
ProviderUri : -----------------------------
DefaultProviderRealm : -
ProviderRealms : {----}
ClaimTypes : {http://schemas.xmlsoap.org/claims/CommonName, http://schemas.xmlsoap.org/claims/EmailAddress, http://schemas.microsoft.com/ws/2008/06/identity/claims/role}
HasClaimTypeInformation : True
ClaimTypeInformation : {Account Name, Email Address}
ClaimProviderName : LDAPCP
UseWReplyParameter : False
UseWHomeRealmParameter : False
RegisteredIssuerName :
IdentityClaimTypeInformation : Microsoft.SharePoint.Administration.Claims.SPTrustedClaimTypeInformation
Description : PingFederate Claims Provider SharePoint
SigningCertificate : [Subject]
                              CN=XXX.XX.XXX.sharepoint.sso.ping.XXX.com, OU=XXX, O=MMC, L=XXX, S=XX, C=US

                            [Issuer]
                              CN=XXX.XX.XXX.sharepoint.sso.ping.XXX.com, OU=XXX, O=MMC, L=XXX, S=XX, C=US

                            [Serial Number]
                            -

                            [Not Before]
                              28/05/2013 15:10:14

                            [Not After]
                              26/05/2023 15:10:14

                            [Thumbprint]
                              -
AdditionalSigningCertificates : {}
MetadataEndPoint :
IsAutomaticallyUpdated : False
Name : PingFederateSTS5
TypeName : Microsoft.SharePoint.Administration.Claims.SPTrustedLoginProvider
DisplayName : PingFederateSTS5
Id : -
Status : Online
Parent : SPSecurityTokenServiceManager Name=SecurityTokenServiceManager
Version : 2923693
Properties : {}
Farm : SPFarm Name=XXXX_Config
UpgradedPersistedProperties : {}
Oct 9, 2014 at 3:46 PM
Hi Yvand,

Do you have any status or suggestion?
Coordinator
Oct 10, 2014 at 12:31 PM
Hello,

as a golden rule, you must never have duplicated claim types in the table, and I will prevent this to happen with the next update.
Regarding the colors, claim types that are found in your trust configuration (that you can retrieve with Get-SPTrustedIdentityTokenIssuer cmdlet) will appear green, which means they will be used by LDAPCP. Identity claim type will appear green bold.

In the output of your trust (Get-SPTrustedIdentityTokenIssuer) I don't see what is the identity claim type but it seems to be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, so this one is the most important.
You don't have http://schemas.xmlsoap.org/claims/CommonName in LDAPCP claims table so you cannot grant permissions on this claim type.
And the roles are set with http://schemas.microsoft.com/ws/2008/06/identity/claims/role.
So you only care about those 3 claim types and you can delete the rest in LDAPCP claims table page.

cheers,
Yvan
Nov 19, 2014 at 5:40 PM
Hi Yvand,

As per your suggestion, i have removed duplicate and added roles are set with http://schemas.microsoft.com/ws/2008/06/identity/claims/role. Now i was able to resolve AD groups and add AD group to the SharePoints.

But when the users from the groups, tried to access to the site, getting access denied. Could you please assist me in the same.

TrustedIdentityTokenIssuser Output:
ProviderUri : https://dev.sso.ping.*****.com/idp/prp.wsf
DefaultProviderRealm : RP:*****GLSHAREPOINTIWASSO
ProviderRealms : {[http://dev.*****share.*****.com/, RP:GLSHAREIWASSO], [http://dev.pilotspdms.*****.com/,
                            RP:*****GLSPDMSPILOTIWASSO], [http://dev.spdms.*****.com/, RP:*****GLSPDMSIWASSO], [http://uat.spdms.*****.com/,
                            RP:*****GLSPDMSIWASSO]}
ClaimTypes : {http://schemas.xmlsoap.org/claims/CommonName, http://schemas.xmlsoap.org/claims/EmailAddress,
                            http://schemas.microsoft.com/ws/2008/06/identity/claims/role}
HasClaimTypeInformation : True
ClaimTypeInformation : {Account Name, Email Address, Account Name}
ClaimProviderName : LDAPCP
UseWReplyParameter : False
UseWHomeRealmParameter : False
RegisteredIssuerName :
IdentityClaimTypeInformation : Microsoft.SharePoint.Administration.Claims.SPTrustedClaimTypeInformation
Description : PingFederate Claims Provider SharePoint
SigningCertificate : [Subject]
                              CN=dev.gl.*****.sharepoint.sso.ping.*****.com, OU=*****, O=MMC, L=*****, S=NJ, C=US

                            [Issuer]
                              CN=dev.gl.*****.sharepoint.sso.ping.*****.com, OU=*****, O=MMC, L=****, S=NJ, C=US

                            [Serial Number]
                              013EEB7995A2

                            [Not Before]
                              28/05/2013 15:10:14

                            [Not After]
                              26/05/2023 15:10:14

                            [Thumbprint]
                              7EC78CD5CC7F4A8259CAE5162372E6E8CDE601B9
AdditionalSigningCertificates : {}
MetadataEndPoint :
IsAutomaticallyUpdated : False
Name : PingFederateSTS5
TypeName : Microsoft.SharePoint.Administration.Claims.SPTrustedLoginProvider
DisplayName : PingFederateSTS5
Id : bb1c96e1-592e-4a1c-86c1-40e6f4746ce7
Status : Online
Parent : SPSecurityTokenServiceManager Name=SecurityTokenServiceManager
Version : 3304826
Properties : {}
Farm : SPFarm Name=_Config
UpgradedPersistedProperties : {}

Claim Table mapping:
Table below displays the relationship between claim types and LDAP attributes, used by LDAPCP.
Claim type LDAP attribute LDAP object class Actions
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname givenName user Edit DeleteSave Cancel
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Edit DeleteSave Cancel
http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group Edit DeleteSave Cancel
linked to identity claim displayName user DeleteSave Cancel
linked to identity claim cn user DeleteSave Cancel
Used as metadata for the permission created title user DeleteSave Cancel
Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user DeleteSave Cancel
Used as metadata for the permission created telephoneNumber user DeleteSave Cancel


ULS Logs Of AD Group Resolving and adding:
Resolving the user:
LDAPCP] The LDAP Query "(|(&(objectclass=user) (sAMAccountName=
GLOBAL-SP-GSDM-S-G
))(&(objectclass=group) (sAMAccountName=
GLOBAL-SP-GSDM-S-G
))(&(objectclass=user) (displayName=
GLOBAL-SP-GSDM-S-G*))(&(objectclass=user) (cn=GLOBAL-SP-GSDM-S-G)))" returned 1 result(s)
[LDAPCP] Created permission with claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to the list of results.
[LDAPCP] Added permission created with LDAP lookup: claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to the list of results.

Adding AD Group:
LDAPCP] The LDAP Query "(|(&(objectclass=group) (sAMAccountName=global-sp-gsdm-s-g)))" returned 1 result(s)
[LDAPCP] Created permission with claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to the list of results.
[LDAPCP] Validated permission with LDAP lookup. claim value: GLOBAL-SP-GSDM-S-G, claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
LDAPCP] The LDAP Query "(|(&(objectclass=group) (sAMAccountName=global-sp-gsdm-s-g)))" returned 1 result(s)
LDAPCP] Created permission with claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to the list of results.
LDAPCP] Validated permission with LDAP lookup. claim value: GLOBAL-SP-GSDM-S-G, claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
[LDAPCP] The LDAP Query "(|(&(objectclass=group) (sAMAccountName=global-sp-gsdm-s-g)))" returned 1 result(s)
[LDAPCP] Created permission with claim value: "GLOBAL-SP-GSDM-S-G", claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" to the list of results.
[LDAPCP] Validated permission with LDAP lookup. claim value: GLOBAL-SP-GSDM-S-G, claim type: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
Coordinator
Nov 20, 2014 at 11:18 AM
Hello,
it looks like the 3rd party STS (ADFS or whatever) does not include the groups (or not in correct format) in the SAML token delivered to users.
You can verify this with a Fiddler/HTTP trace when user authenticates and returns to SharePoint, the SAML token will be readable and you can verify if/how groups are added.
cheers,
Yvan
Nov 20, 2014 at 7:41 PM
Hi Yvand,

Thanks for the quick response. In our Environment, we have Ping federated configured. It will be great helpful to us, if you can share us. The configuration need to be included on Ping configuration to include Group and users. i don't have deep insight on ping federated configuration.

I can contact the Ping team to check for the configuration and if its missing. I can instruct them to include it. Thanks in Advance.
Nov 26, 2014 at 6:59 PM
Hi Yvand,

Could you please assist us with our previous post. Addition to that, is that possible to map two claim type to same LDAP attribute?
Thanks in Advance.
Coordinator
Nov 27, 2014 at 11:39 AM
Hello, I don't have any knowledge in Ping Federate so I cannot be of any help.
Before the last update you could map a LDAP attribute/class to 2 different claim types, but in v3.4 I added a check to prevent this, as I couldn't imagine this would make sense.
Why would you do that? I could allow it back if it really makes sense.
Cheers,
Yvan
Dec 5, 2014 at 3:39 PM
Did anyone ever get a resolution to this? We are having the same issue with this tool and PingFederate. We can get in to our sites with the user accounts, but AD groups are not being mapped.
Dec 8, 2014 at 2:44 PM
Hi Slevin,

I dont think you can use Ping Federate to resolve claims/attributes in people picker.

Ping Federate can only act as a Service Provider/Authentication provider, as far as i know.

This is how Ping works:
When you sign onto a SharePoint site, your web app's default sign-in will redirect you to Ping Authentication page(example: federation.company.com/prp.idf), which will then connect in the back-end to your authentication store(Active Directory or LDAP) with the credentials you provide and then authenticate you by issuing a SAML 1.1 token, which then redirects you to SharePoint, where you are issued a FedAuth cookie.

So, although you get signed into SharePoint, remember that you are not directly connected to your Authentication Store, Ping acts as a middle man. So whenever you try to resolve a name using people picker, it doesn't know where to get the name resolution from, as Ping does not help you connect to an authentication store real-time, it will only do that when you are logging into the site.

Unless you have modified the LDAPCP code to query against your Authentication store or if you are using a newer version of PingFederate, that i am not aware of, which may be capable of doing a real-time lookup against a directory store.
Dec 8, 2014 at 8:29 PM
Hi Naveen,

I agree with you. Ping Federated will not assistance us for resolving users/group in people picker. We are facing issue in the next stage.

User of the active directory group are getting access denied. In our environment, we have configured LDAPCP to query for AD Group with Cliam type "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" and AD Groups are resolving. I have added AD Group "Testing_SharePoint" to one of the SharePoint Site.

We have configured Ping Federated to include AD group to pass as SAML assertion in response with Attribute Name Space "http://schemas.microsoft.com/ws/2008/06/identity/claims/role". we are using SAML 2.0.

All the Groups, the user belongs too in SAML.
<saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>testing_Sharepoint</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>SharePointGroup1</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>SharePointGroup2</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
Tried it with reducing the Logon Token, Window Token Life time and Form Token Life time. Still, the user of the AD groups are getting access denied.

If possible, could you please assist us in the same. Thanks in Advance.
Dec 8, 2014 at 10:22 PM
Slevin,

I think i understand what your issue is here.

You have a claim called 'role', Which is a multi-value claim. Using which you are giving access to a SharePoint Trusted Identity Hosted Site , is that right ?

What type of authentication methods are you using on this particualr Web Application ?
Dec 9, 2014 at 1:33 AM
Hi Naveen,

Thanks for the quick response. Yes, you are correct.

We are using trusted Identity Provider "PingFederatedSTS".

If its Multi-value claim "Role", whether we need to mentioned that explicitly in configuration for SharePoint to accept claim from Ping Asseration?

Could you please assist us in resolving the issue.

Thanks in Advance.
Dec 9, 2014 at 2:02 PM
Edited Dec 9, 2014 at 2:09 PM
Slevin,

Sorry for the late reply.

I Suppose that the SAML generated by your Ping Fed, is
<saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>testing_Sharepoint</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>SharePointGroup1</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>SharePointGroup2</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
So, which means you are passing in 3 groups to the assertion.

Okay, then in that case, the only thing that you might be doing wrong would the way you are providing access to the users.

Follow the screenshots below and see if this is how you are granting permissions to users using group claim. The name of my group claim is 'Application Group', yours would be 'role'.

Choose the group claim

Enter the name of the Group

Resolve the Group

Select the resolved entity

Finally group claim added to SharePoint Group

Follow these images and try the same on your environment, i think you may be providing access the wrong way.

Let me know how it goes. If you can past the images here or links to the images which explain how you are providing access, just like i did here.

Hope this helps.
Dec 9, 2014 at 2:46 PM
Hi Naveen,

We are using Claims Authentication using SAML 1.1 with Ping. With ping, we do have to maintain an alternate identity, meaning that each person will have two identities: One from AD, and one from Ping. I used LDAPCP to allow the people picker to resolve both identities and AD groups, but my issue is that people do not seem to be able to authenticate with the "ping version" of the AD groups. For example, if I am user1 and I am a member of the AD group "ADLeaders", I should be able to get to the site if any of the 4 items were added to the site permissions:

domain\user1
i:07.t|pingfederatests5|user1
domain\ADLeaders
(Role) AD Leaders


The last one is how the AD groups are coming into the people picker. Here is what I have for the claims mapping, which I had to adjust the 'givenname' entry to point to the LDAP Attribute "sAMAccountName"

Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user Email User
Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user User
Edit http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname sAMAccountName user User
Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Location FormsRole
Edit Delete http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group FormsRole
Delete linked to identity claim displayName user DisplayName User
Delete linked to identity claim cn user User (!(objectClass=computer))
Delete linked to identity claim sn user User
Delete Used as metadata for the permission created title user Title User
Delete Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user SIPAddress User
Delete Used as metadata for the permission created telephoneNumber user WorkPhone User


SO my question is still, given this information, is there something we need to do either on SharePoint's side or Ping's side that we can authenticate with both AD groups and the individual accounts.
Dec 9, 2014 at 2:53 PM
Hi Naveen,

We are following the same steps for provision AD groups to the SharePoint, but still we are getting access denied.

Only difference i found that infront of AD Group, its was append with Attribute Name.

Example as below:

Account Name: c:0-.t|pingfederatests5|global-sp-gsdm-s-g
Name: (Role) GLOBAL-SP-GSDM-S-G

Please let me know, if you required any additional information.

Thanks in Advance.
Dec 9, 2014 at 3:40 PM
Slevin,

Would you be able tell me if you have more than one Authentication method specified on your web application.

To get this information you would go to , Application Management, Manage Web Applications, Select your Web Application and click on Authentication Providers.

And you will see zones. Tell me how many zones you have.

Also for each zone what type of authentication method is selected, like anonymous, or Trusted Identity Provider or NTLM or Forms ?

Based on your reply i feel that you should have both NTLM and Trusted Identity Provider selected.
Dec 9, 2014 at 3:47 PM
Hi Naveen,

We have three Zone configured for the web application:

Default Zone - NTLM
Intranet - Trusted Identity Provider
Extranet - FBA

Thanks in Advance.
Dec 9, 2014 at 4:24 PM
We have just have the default zone (Claims Based Authentication). We are suing NTLM Authentication and Trusted Identity Provider (PingFederateSTS5).
Dec 9, 2014 at 4:45 PM
Slevin,

Okay, so i assume that you are trying to figure out this issue on Intranet Zone Url, Is that right ?

Did you do a fiddler trace and check the saml assertion in the respose header ?

What does the header show, does it show the saml assertion that you have pasted in one of your previous replies ?

Can you do one thing, download this Webpart Claims Viewer WebPart

Deploy and Install, and then add this webpart to a new page on your site, log onto the site using a valid TIP ID.

And then post me or mail me a screen shot of what you see on the claimsviewer webpart.

Here is one from my test environment: Claims Viewer
Dec 9, 2014 at 4:54 PM
Edited Dec 9, 2014 at 4:54 PM
Slevin,

May be a screenshot from your fiddler trace, without any PII information would be helpful.

I need the info of SAML assertion when you sign onto the site where you get access denied.

This will help me figure out quickly what could have gone wrong.
Dec 9, 2014 at 4:55 PM
HI Naveen,

You are correct, the issue with Intranet Zone URL.

Yes, i have reviewed SAML asseration from fiddler trace and too from Ping server for response. I have received the same, i have posted in my earlier response.

Sure, i will try to downlaod and deploy the solution in our environment. What you mean by valid TIP ID.

Are you asking to login with my ID after provising it directly instead of AD Group.
Dec 9, 2014 at 4:56 PM
Edited Dec 9, 2014 at 4:58 PM
Yes Sure. I will fiddler trace of SAML asseration with PII information.

One small clarification, we can deploy the solution on SharePoint 2013 Farm.

In description, it was mentioned for SharePoint 2010.
Dec 9, 2014 at 4:57 PM
Slevin,

Yes a valid TIP ID , i mean is an id that is able to log onto your Intranet Zone Url.
Dec 9, 2014 at 5:56 PM
Can the webpart be used in SharePoint 2013? That is the environment we are using
Dec 9, 2014 at 7:11 PM
Hi Naveen,

Please find the below SAML Asseration collected.
<saml:Assertion Issuer="*****GL*****SHAREIWASSOIDP:IDP" IssueInstant="2014-12-09T18:56:24.105Z" AssertionID="gzY2aPzS-r2yOh7kYlKRqYWm8P1" MinorVersion="1" MajorVersion="1">
  <saml:Conditions NotOnOrAfter="2014-12-10T02:56:24.105Z" NotBefore="2014-12-09T10:56:24.105Z">
    <saml:AudienceRestrictionCondition>
      <saml:Audience>RP:*****GL*****SHAREIWASSO</saml:Audience>
    </saml:AudienceRestrictionCondition>
  </saml:Conditions>
  <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified" AuthenticationInstant="2014-12-09T18:56:24.104Z">
    <saml:Subject>
      <saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/CommonName">MFAROOK</saml:NameIdentifier>
    </saml:Subject>
  </saml:AuthenticationStatement>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/CommonName">MFAROOK</saml:NameIdentifier>
    </saml:Subject>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="Role2">
      <saml:AttributeValue>[CN=GLOBAL-SP-GSDM-S-G,OU=SharePoint,OU=Applications,OU=Groups,DC=*****,DC=*****,DC=com, CN=GLB-RAS-QuickConnect-L,OU=Services,OU=Remote Access,OU=Enterprise Systems,DC=*****,DC=*****,DC=com, CN=GLB-RAS-OWA-L,OU=Services,OU=Remote Access,OU=Enterprise Systems,DC=*****,DC=*****,DC=com]</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="CommonName">
      <saml:AttributeValue>MFAROOK</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="EmailAddress">
      <saml:AttributeValue>Mohamed.Farook@*****.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="Group">
      <saml:AttributeValue>GLOBAL-SP-GSDM-S-G</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="Group">
      <saml:AttributeValue>GLB-RAS-QuickConnect-L</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/claims" AttributeName="Gruop">
      <saml:AttributeValue>GLB-RAS-OWA-L</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>GLOBAL-SP-GSDM-S-G</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>GLB-RAS-QuickConnect-L</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" AttributeName="Role">
      <saml:AttributeValue>GLB-RAS-OWA-L</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
I will share Claim Viewer Web part details.

Please let us know, whether we can use the web part in SharePoint 2013 Farm.
Dec 9, 2014 at 8:02 PM
Slevin,

I see that you have two claims, role and group, which bring in the same data.

the one last thing i would need to know is how to provide access. Is there anyway you can show me how you provide access, the way i did it in my screenshots ?

Also, here is the url, where you can find a SP2013 claims viewer web part.
Dec 9, 2014 at 8:40 PM
Hi Naveen,

I sent the SAML assertion in a DM to you. I will post the rest of the information you requested shortly
Dec 9, 2014 at 9:54 PM
Slevin,

I saw the SAML assertion you sent, i dont see a lot in there, but the one above your reply shows it all.

My guess is, because you are having NTLM and Trusted Identity Provider both selected, when you are trying to resolve your ad groups, it could be that you are actually resolving the AD group with NTLM authentication.

Can you try one thing, just to isolate the issue, would you please remove NTLM authentication ( un-check the NTLM ) from your Intranet Zone authentication provider.

and then add AD group with just the name of the group, without domain,( like GLOBAL-SP-GSDM-S-G). and then sign onto the site, with the user account present in this group. or use any other group that you are a part of and add it to the site, then log onto the site and test it.

Make sure you remove any explicit permissions that you may have to your id, before testing with the AD group.
Feb 25, 2015 at 5:08 PM
Hi Slevin,

We're having a similar issue to yours - using PingFederate as the STS and LDAPCP to present a modified PeoplePicker, we haven't been able to use AD security groups for SP permissions yet.

On the Ping side, what AD attributes are you mapping to "Roles" and "Groups" for the SAML assertion?
Mar 17, 2015 at 2:10 PM
We are also using PingFederate and having the same issue where AD security groups are coming through, with (role) listed in front of the security group in the people picker. Our claims table information is below. If someone could assist, it would be appreciated as this is a big issue for us!

Edit http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mail user displayName Email User
Edit Delete http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname sAMAccountName user User (!(objectClass=computer))
Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn userPrincipalName user User
Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname givenName user User
Edit Delete http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality physicalDeliveryOfficeName user Location FormsRole
Edit Delete http://schemas.microsoft.com/ws/2008/06/identity/claims/role sAMAccountName group FormsRole
Delete linked to identity claim displayName user DisplayName User
Delete linked to identity claim cn user User (!(objectClass=computer))
Delete linked to identity claim sn user User
Delete Used as metadata for the permission created title user Title User
Delete Used as metadata for the permission created msRTCSIP-PrimaryUserAddress user SIPAddress User
Delete Used as metadata for the permission created telephoneNumber user WorkPhone User