Quantcast
Channel: LDAP/AD Claims Provider For SharePoint
Viewing all 270 articles
Browse latest View live
↧

New Post: LDAP CP Configuration settings

January 3, 2017, 5:26 am
$
0
0
Hello,

We're using LDAPCP_Custom solution and observed that the LDAP CP Configuration pages in central admin are not working and LDAPCP_Custom is not taking the settings from LDAP CP Configuration pages anymore.

Can you please advise on how we can make LDAPCP_Custom solution to continue using the LDAP CP Setting pages.

Appreciate your quick response on this.

Thanks,
Vamshi
↧
Search

New Post: LDAP CP Configuration settings

January 11, 2017, 4:42 am
$
0
0
Hello,
with the latest version I moved the admin pages into user controls, so it should be fairly simple to do but I never tried...
If you want to give it a try, you can create a page that adds user controls in markup code, and sets their properties in code behind of the page.
thanks,
Yvan
↧
↧

New Post: Unexpected error in Augment

January 16, 2017, 3:32 am
$
0
0
The augmentation doesn't work all the time.
  • When it doesn't work some users it works for others (random)
  • It's not frontend specific
Can you help us out?

01/16/2017 09:35:48.16 w3wp.exe (0x16BC) 0x1580 LDAPCP Augmentation 1337 Unexpected [LDAPCP] Unexpected error in Augment: System.Runtime.InteropServices.COMException: Creating an instance of the COM component with CLSID {080D0D78-F421-11D0-A36E-00C04FB950DC} from the IClassFactory failed due to the following error: 800401e4 Invalid syntax (Exception from HRESULT: 0x800401E4 (MK_E_SYNTAX))., Callstack: at System.DirectoryServices.ActiveDirectory.DirectoryEntryManager..ctor(DirectoryContext context) at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context) at ldapcp.LDAPCP.GetLDAPServers(RequestInformation requestInfo) at ldapcp.LDAPCP.<>c__DisplayClass46_0.<Augment>b__0() 7d89cb9d-dda2-00a4-8c3b-ea323180c760
↧

New Post: Unexpected error in Augment

January 17, 2017, 8:10 am
$
0
0
Interesting, can you please give me more insight:
  • Does this error occur only during augmentation?
  • Can you confirm you use the default LDAP connection?
  • Do you have other custom LDAP connections?
  • Does it always fail for the same users?
  • If error occurs, will it continue to occur for everyone until you recycle the pool, or does it resolve on its own?
According to the callstack it fails at this instruction:
DirectoryEntry de = Domain.GetComputerDomain().GetDirectoryEntry();
Error itself is very unclear on what may cause it...
↧

New Post: Source Code Version

January 18, 2017, 5:47 am
$
0
0
Hello,

i'm not sure but it seems i can't get source for Version 5.1 of LDAPCP.
Why there is the last commit for Version 4.0 in source tree.

How i can get source for Version 5.1

Regards,
Joerg
↧
↧

New Post: Unexpected error in Augment

January 19, 2017, 4:45 am
$
0
0
Does this error occur only during augmentation?
Yes, did some searches on IClassFactory and syntax in the ULS logging, only shows up in augmentation.

Can you confirm you use the default LDAP connection
Yes
Current LDAP connections = Connect to SharePoint domain

Do you have other custom LDAP connections?
No

Does it always fail for the same users?
No quite random, but in the same small little pool of users (The SharePoint farm isn't officially live yet, but is ready except for the augmentation).

If error occurs, will it continue to occur for everyone until you recycle the pool, or does it resolve on its own?
I haven't seen it resolve by itself yet, it usually ends up with me disabling and enabling the recycling the AppPool.
↧

New Post: Unexpected error in Augment

January 19, 2017, 5:36 am
$
0
0
Hmm, it's interesting that it fails only with augmentation.
Augmentation happens only in the STS of SharePoint, which runs with the farm account, whereas all other requests made by LDAPCP run in the w3wp of the site.
So I wonder if there could be something special with your farm account that could cause this...
Can you confirm you use a different account for the application pool of the sites?
If so, could you maybe try to create a test web app that runs with the farm account, and see if you can repro during search in people picker?
↧

Created Unassigned: Cannot pick AD groups with the picker [2541]

January 19, 2017, 1:08 pm
$
0
0
We managed to configure the picker, but noticed that we cannot resolve/add AD groups when we have it enabled. Am I missing something? Can someone please advise how to configure it properly so ut can resolve AD groups?
↧
Search

Created Unassigned: Default exclude AD local domain groups via LDAP filter [2542]

January 20, 2017, 2:29 am
$
0
0
According to MS best practices ADFS does not add local domain group memberships as "role" claim,
since these type of AD groups shouldnt contain users

Only AD global and universal groups should contain users and memberships are added by default (as a "role" claim to the SAML token).

Would it be an idea to add the following LDAP filter by default to the "role" claim in LDAPCP to exclude these groups: (|(groupType=-2147483646)(groupType=-2147483640))

This prevents users from selecting local domain groups, which by default cannot be used for authorisation purposes






↧
↧

New Post: Please update roll back procedure

January 20, 2017, 5:36 pm
$
0
0
Hi,

I spent a fair amount of time in uninstalling LDAPCP . The LDAPCP is listed as Claimsprovider even after deactivating the feature and removing it . It does not change back to default .

I used below command to change it back to default (null). Please update this in document/roll back steps so that others don't have to recreate the SPTrustedIdentityTokenIssuer


$sts = Get-SPTrustedIdentityTokenIssuer "XXXX"
$sts.GetType().GetField("m_ClaimProviderName","NonPublic,Instance").SetValue($sts, $null)
$sts.Update()
↧

New Post: Please update roll back procedure

January 23, 2017, 4:59 am
$
0
0
hello,
I really wish there is an easier way that does not involve to remove and recreate the SPTrustedIdentityTokenIssuer object, but your script uses reflection to reset property m_ClaimProviderName, which is not supported, so I can't recommend it.
However I agree I should mention that LDAPCP will still be referenced in the SPTrustedIdentityTokenIssuer object after it's removed. I'll update the page to mention that.
Thank you for your input,
Yvan
↧

New Post: Group Augmentation

January 25, 2017, 4:01 am
$
0
0
Hi there,

Having a crash course on SAML, Sharepoint and claims to implement a solution so apologies if I've got something simple wrong.

To set the scene I have a SAML IdP providing 2FA to a Sharepoint 2016 install, this works and users get in, if I add the short form group name that my IdP sends in the People Picker then users get in ok.

Customer has a lot of AD groups setup for the normal NTLM auth so wants to reuse that config so LDAPCP seemed like the ideal solution to test, I was presuming we could use it to link the SAML claim to the proper AD groups and Sharepoint would pick that up?.

I think I have it all setup correctly, IdP uses a different claim class for CN and groups so have adjusted them, enable Augmentation and checked the logs and it seems to augment the user but still get no access to the SP site.

Just wanted to check I haven't completely misunderstood or got it wrong as have gone from 0% knowledge of all this since Monday :-)

Pics, of setup attached

Cheers

Nic

Image
Image
Image
Image
↧

New Post: Group Augmentation

January 26, 2017, 8:02 am
$
0
0
Hi Nic,
the configuration looks correct, but did you check how roles are formatted by the IDP?
In the screenshot roles value are "domain users" or "users", so the IDP must send them like this too. And not, for example, "domain\domain users" or "domain\users".
You may also double check that the claim type for the role is the same between the IDP and LDAPCP
thanks,
Yvan
↧
↧

New Post: Group Augmentation

January 26, 2017, 9:07 am
$
0
0
Hi Yvan,

Thanks for the reply, yes the IdP sends the same format value and claim type, SSO tracer shows the following in the assertion

<saml:Attribute AttributeName="Group" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>Sharepoint Users</saml:AttributeValue></saml:Attribute>

Have I got it right that using LDAPCP should map the groups over so that the User Policy that was configured for the NTLM users should still work for the SAML users?
Looking at the policy is shows the GroupSID. I also wondered if it was because I was using a different claim type and not the http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid I see when looking at the claim details for a NTLM log in?

I am just guessing there as not completely got my head around everything

Cheers

Nic
↧

New Post: Group Augmentation

January 30, 2017, 8:18 am
$
0
0
Hello Nic,
So your IDP configuration matches LDAPCP config, but you cannot use the Windows groups claim types, you must migrate them to the role claim type you defined in the SPTrustedIdentityTokenIssuer object that you created
For this I recommend that you use SPFarm.MigrateUserAccount() method:
# Migrate WinClaim group to  trust "localad" with claim type http://schemas.microsoft.com/ws/2008/06/identity/claims/role
$oldlogin="c:0+.w|s-1-5-21-889601965-842656306-4080565960-135608";
$newlogin="c:0-.t|localad|myazure.local\dmgroup2";
[Microsoft.SharePoint.Administration.SPFarm]::Local.MigrateUserAccount($oldlogin, $newlogin, $false);
thanks
Yvan
↧
Search

New Post: Group Augmentation

January 31, 2017, 7:36 am
$
0
0
Ahhhh ok that sort of makes sense :-) so because the claim type is 'w' for a windows claim the SAML claim doesn't apply?

If I change the role though I presume that basic Windows authenticated users won't then be able to access the site?
↧

New Post: Group Augmentation

January 31, 2017, 8:39 am
$
0
0
True and true :)
if you don't want to migrate the role account (for the good reason that you mentioned), you can simply create a new one in trusted (SAML) format, through the people picker
↧
↧

New Post: Group Augmentation

January 31, 2017, 8:49 am
$
0
0
Super super, think I misunderstood the purpose of LDAPCP augmentation, was hoping that the information it populated the claim with would enable the existing Sharepoint permissions to "just" work.

It certainly makes the people picker easier to navigate though our IdP sends the group info through in the ticket anyway so if we want both AD and SAML authentication to work we really need to define two seperate rules in the picker.

On the upside I've learnt a lot about Sharepoint, SAML and claims over the last week, which is good as off to Paris tomorrow to see customer :)

Thanks for the help.
↧

New Post: Group Augmentation

February 2, 2017, 4:54 am
↧

New Post: mistake in uninstalling the ldapcp

February 8, 2017, 12:22 pm
$
0
0
Yvand wrote:
Where are you looking at?
In .NET 4.5, GAC is located in C:\Windows\Microsoft.NET\assembly
I am using version 3 of the ldapcp code on a .Net 4.5 machine. The ldapcp.dll is installed across C\Windows\Assembly and not C\Windows\Microsoft.Net\Assembly.
Do I need to copy and paste the dll into the new GAC location?

Also does dll need to be on web server, app server, and database server?

Another Note: When running this code below on the .net4.5 server the ldapcp code is just placed in C\Windows\Assembly and not C\Windows\Microsoft.Net\assembly
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("c:\ldapcp.dll")
iisreset
↧
Viewing all 270 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>