Comments for Yet another identity management blog

Comment on FIM, System.DirectoryServices and a memory leak by Steve Kradel

Steve Kradel — Wed, 22 May 2013 16:21:59 +0000

Well, S.DS and its close relatives are basically wrappers around the old ADSI / COM classes, which have some drawbacks like difficulty working with custom attributes, memory issues, and more complex network interaction via RPC. The union of .NET and COM is often very complex, and can set the stage for bizarre bugs at scale. On the other hand, S.DS.P is much closer to plain LDAP–lightweight, interoperable with a variety of DSAs, provides access to a wide range of LDAP request controls, async mode, etc., and just more “manageable” for the CLR.

Comment on FIM, System.DirectoryServices and a memory leak by Thomas Vuylsteke

Thomas Vuylsteke — Tue, 21 May 2013 20:53:53 +0000

Steve, I myself rarely get in touch with S.DS, S.DS.AD and S.DS.P. From here (http://msdn.microsoft.com/en-us/library/bb332056.aspx ) I can see on the picture that they are more or less alternatives for each other S.DS/S.DS.AD vs S.DS.P I’m really interested as to why S.DS.P is “the way to go”. Could you elaborate a bit more?

Comment on Editing the FIM Portal web.config in a farm topology by Paul Williams

Paul Williams — Fri, 17 May 2013 08:02:10 +0000

It’s probably worth noting that while this is more important in a farm than with multiple stand-alone instances the web.config changes will be lost whenever you patch the FIM portal unless you make the change via SharePoint’s API, i.e. this isn’t just applicable to a farm. The process of adding the requireKerberos element, for example, to the web.config file via direct modification is not recommended as the programmatic management of the file will remove that change each time you patch.

Comment on FIM Portal in a SharePoint farm–why you should not do this by Editing the FIM Portal web.config in a farm topology | Yet another identity management blog

Fri, 17 May 2013 07:55:04 +0000

[…] ← FIM Portal in a SharePoint farm–why you should not do this […]

Comment on FIM Reporting Extract, Transform and Load (ETL) process by Mannn

Mannn — Thu, 16 May 2013 08:43:55 +0000

Good and very helpful Article!

Comment on Active Directory Federation Services (AD FS) 2.0 and multiple AD DS forests by Paul Williams

Paul Williams — Wed, 15 May 2013 05:11:40 +0000

Hi Fabrice,

A unidirectional trust works assuming the service account can read the AD that the users reside in, which generally means the service account exists in the user domain:

“Because the service account running the AD FS farm is a principal in infra.adatum.com a bidirectional trust is needed, as the service account performs attribute value lookups, using LDAP, in the users.adatum.com domain. If the service account belonged to the users.adatum.com domain a unidirectional trust between the domains (incoming in users.adatum.com, i.e. users.adatum.com users can authenticate in infra.adatum.com) would suffice.”

In my case my original lab was what prompted the post in the first place, i.e. where does the service account reside in a multi-domain environment.

If your users are authenticating to your FS over a one-way trust then two things spring to mind:

1. It’s actually a two-way trust; or
2. Anonymous LDAP reads are enabled

The FS queries the domain that the user exists in to get UPN, group membership, etc. This query cannot happen with a one-way trust and the default settings.

Comment on Active Directory Federation Services (AD FS) 2.0 and multiple AD DS forests by Fabrice Osswald

Fabrice Osswald — Tue, 14 May 2013 14:23:57 +0000

Hi Paul,

I actually configured a scenario like in Example 1 where ADFS 2.0 service account is declared in infra.adatum.com domain and there is only an unidirectional trust between infra and users domains : infra domain trusts users domain. Yet, the configuration works : users accounts from users domain manage to authenticate through ADFS. So I think that the bi-directional trust is not a prerequisite…
Have you also tested this configuration ?

Comment on FIM Reporting Extract, Transform and Load (ETL) process by FIM Reporting Extract, Transform and Load (ETL) process | FIMSpecialist

FIM Reporting Extract, Transform and Load (ETL) process | FIMSpecialist — Fri, 10 May 2013 16:34:54 +0000

[…] Williams over at Microsoft has just released a great article on the FIM Reporting Extract, Transform and Load (ETL) process within FIM 2010 R2, and it’s […]

Comment on FIM Reporting Extract, Transform and Load (ETL) process by sami

sami — Fri, 10 May 2013 14:03:34 +0000

Very informative–thanks for posting.

Comment on FIM, PowerShell and DateTime type attributes by Paul Williams

Paul Williams — Tue, 23 Apr 2013 13:04:08 +0000

Looks like this is a limitation in the cmdlet – it doesn’t correctly identify an empty string and handle that specific scenario. Work around is to set the value to [DateTime]::MaxValue or [DateTime]::MinValue, depending on the purpose of the attribute. Or use an alternative WCF client of course. Sorry…