MSFT Documentum connector and TCS Troubleshooting

Article
03/05/2012

MSFT Documentum connector and Custom Security Trimming (TCS) Troubleshooting

Summary:

With the release of the Feb 2012 CU for FAST Search PFE has been supporting the SharePoint Documentum connector with custom security trimming in FAST Search. This guide is an expanding set of data points I have run into while troubleshooting.

Official documentation:

Configure TCS support for the Documentum connector (FAST Search Server 2010 for SharePoint)

https://technet.microsoft.com/en-us/library/hh857341.aspx

My post on the subject:

Enable custom security trimming with FAST Search for Sharepoint and Documentum

https://blogs.msdn.com/b/kristopherloranger/archive/2012/03/02/enable-custom-security-trimming-with-fast-search-for-sharepoint-and-documentum.aspx

Pre reqs:

First thing it is absolutely imperative that the technet pre-reqs are filled as the connector is very stringent on pre-reqs.

https://technet.microsoft.com/en-us/library/ff756030.aspx

It is recommended that this hotfix be installed:

https://support.microsoft.com/kb/2459111

Recommended but not necessary, DCTM connector SP1 update:

https://www.microsoft.com/download/en/details.aspx?id=26608

EMC assembly DLLS:

These files should be installed on the SharePoint crawler component server in

%local%\emc-dfs-sdk-6.5\emc-dfs-sdk-6.5\lib\dotnet

In the GAC as well as the FAST FS4SP server in %FASTSEARCH/bin/

Right click on the files and look at properties, you should see

"6.5.0.231 - AKA6.5 SP2 12/5/2009"

This has caused most of the problems I have seen in the field.

Emc.Documentum.FS.DataModel.Core.dll, version number 6.5.0.231
Emc.Documentum.FS.DataModel.Shared.dll, version number 6.5.0.231
Emc.Documentum.FS.runtime.dll, version number 6.5.0.231
Emc.Documentum.FS.Services.Core.dll, version number 6.5.0.231

Security Sync Crashing or not downloading user ACLs

The logging for the Security Sync service can be to debug for more information on your issue in the %FASTSEARCH/bin/Microsoft.SharePoint.Search.Extended.Security.TrimmingSync.exe.config file. Adjust the logLevel, restart the service and the logFilename settings
here. By default, this log file should be at this location:

%FASTSEARCH%\var\log\SecTrimmingLog.txt

Networking:

Since most environments you will be going over multiple networks a very quick networking test is from the FS4SP sync node check this file then run the below telnetcommand:

telnet dctm.contoso.com 443

Ç♥☺fPS…

You can find the system to test in you $FASTSEARCH/bin/Microsoft.Sharepoint.search.extended.security.trimmingsync.exe.config

<DataSource.Documentum

password="******"

repository="DCTM_dev"

dfs="https://dctm.contoso.com/dctm/services" />

All users(with a login) are seeing all documents:

Aka security is not working.

Overwrite attribute:

Make sure you have edited %FASTSEARCH%\etc\CustomSecurityTrimming.xml file:

Changing this from the default value “0” will alter the behavior and strip away any other values that may have been set earlier in the pipeline stage which usually includes NT style authentication.

Note:

If you have this problem and change the value you will have to run a full crawl again once this value (or index-profile) is changed.

Index-profile:

If you have a custom IP you may have the docacl field set to not index, this needs to be an index able field.

FASTSEARCH/index-profiles/index-profile-fs14

Are we getting DCTM ACLs in the FiXML?

Run a Get-FASTFixml on a known DCTM document and look for “bcondocacl”

Here we see 4 claims, the 1^st being an NT ACL and the other 3 being DCTM, this is what it would look like if we had the Over write attribute set to 0 marked above. We Just want to see the ACLs similar to these.

Get-FASTFiXML script:

https://gallery.technet.microsoft.com/scriptcenter/14105abb-29da-43fd-90f4-ac12f1a0233a

Are you even getting ACL information from the DCTM server?

Turn on FFDDumper, instructions on TechNet:

https://technet.microsoft.com/en-us/query/hh285835#debug_log

Open the files FFDDumper is creating, you are looking for docacl fields with GUIDs similar to this:

34972762-7E3F-4F4F-AE5C-5ABBA92EC530:Return.DocumentumACL:31

Feeding Pipeline:

These two points should be added automagically when running the enable security trimming powershell script during install, always a good point to double check.

Check your pipeline to make sure the processing is set, this should be set here:

%FASTSEARCH%\etc\config_data\DocumentProcessor\OptionalProcessing.xml

Check the following in the pipelin configuration:
%FASTSEARCH%\etc\pipelineconfig.xml

</processor>

…

Note: If you make changes here, execute the following command psctrl.exe reset or restart FastSearch for SharePoint 2010

Machine.config security and sync problems:

By default the crawler machine.config is different than the custom security sync patch config, they should both have the setting.

%FASTSEARCH/bin/Microsoft.SharePoint.Search.Extended.Security.TrimmingSync.exe:

C$\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config:

SamWorker Log

Also you can turn on the debug logging for the authorization worker by opening the PowerShell for FAST search for SharePoint 2010 and issue
the following command:

Set-FASTSearchSecurityLogLevel -DefaultLogLevel Debug

The log file is located at:
%FASTSEARCH%\var\log\syslog\authorization-worker_<HOSTNAME>.log

Comments

Anonymous
July 10, 2012
Thanks for this great post, Kristopher. Do you have any idea why the CustomSecurityTrimming stage is doing base-32 encoding on the Documentum ACLs? The Windows ACLs are actually SIDs in byte arrays (i.e. binary data), so it is necessary to base-32 encode them in order to store them as strings. But the Documentum ACLs are already UTF-8 strings. When you base-32-encode those strings, they expand into enormously long strings, seems totally unnecessary.
Anonymous
August 08, 2012
Also, in your subtitle "MSFT Documentum connector and Custom Security Trimming (TCS) Troubleshooting" you imply that TCS stands for Custom Security Trimming, but I believe it stands for Trusted Content Services, which is an addon feature of Documentum, right?
Anonymous
May 20, 2014
Hi, i hope you can really help me in this, we enabled the above but it doesn't work and we followed your article but still all users can see all the results and somehow we find everyone SID is in the FiXML, question please, if Documentum team are using virtual goups and these groups are not same name in active directory, would enabling TCS work with such virtual groups and mapp it to the AD LDS and result security gets tirmmed? i hope really you can see my comment and reply to me

Share via

MSFT Documentum connector and TCS Troubleshooting

Comments

Additional resources