nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Templating and Workflow impersonation

Aryan

Hi,

We are in the process of upgrading our complete Web content management landscape from TeamSite 6.7.1 SP1 on Win 2003 to TeamSite 7.2.1 on Win 2008. We have faced several issues in this journey some of it resolved with the help of Support and some it we resolved it ourselves.

Installation Path:
1. Fresh install of TeamSite 7.2.0 on Win 2008
2. Upgrade to 7.2.1 from 7.2.0

Now we are facing two major issues which we see as showstoppers for the move to the new version and platform.

1. Editors are not able to generate content in workareas to which they have full access: Editors are not able to generate using any Perl templates after the upgrade. I found that once they are made a part of the Administrator group in the OS they would be able to generate. But we can’t have that and thats a risk to security. Then I went through various forum links and found that post 6.7.1, the impersonation works only if the logged in user, creating the page as local login rights on the TeamSite server (This should not be the case. Technically TSIMP_ is the impersonation user who should have this access, and all the others get impersonated using this user). Here is the forum link: http://devnet.interwoven.com/forums_vb/showthread.php?t=20325&forumid=11&highlight=errCode%3D1385. The second thing I tried is setting impersonation to false on iwutild.cfg for templating and that works. “Modified By” in this case is the user although the owner is SYSTEM. That would not be a big problem for us. But before even fixing it I want to understand whether this is a change in this TeamSite version (not documented at least) or are our server environments different. The point is to understand the root cause and have a rational explanation for the solution. See: http://devnet.interwoven.com/forums_vb/showthread.php?t=24642&forumid=13&highlight=errCode%3D1385. Hence I need advice from you as to what the right course of action is. Which is the right way of working or is this a bug in the version. I should work with impersonate="true" because it does in our old environment with 6.7.1 SP1 and on another box with 6.7.2 on Win 2003.

2. File operations done on WFT body itself before the workflow starts, are not getting impersonated: A file operations that we do in the body of our workflows are not getting impersonated. We embed the name of the file in the DCR and the file itself when the file is passed via a workflow or Translation workflow. After this happens, the value of the "Modified By" should be the user who actually invoked the workflow. But unfortunately this seems to be showing SYSTEM which is not acceptable. This would affect the way users use TeamSite today. It would affect more than 300 users. We are using a customized version of the configurable_default_submit.wft doing some file operations before we actually submit the file. I can understand that external tasks dont get impersonated until the configuration in iw.cfg is changed but all the operations in the body of the workflow should get impersonated - Is this something related to a DLL issue? See post http://devnet.interwoven.com/forums_vb/showthread.php?t=26670&forumid=79&highlight=workflow+impersonation and the missing libeay32.dll file. For me, i cant find this file in the System32 folder. Second point of check - Should I check if my iw-cg-wrapper file is corrupt? How do I do that? Or is this something fundamentally wrong with the workflow sub system in 7.2.1.

Any support references? RTFMs? Posts? would be greatly appreciated.

P.S. Pardon me if I have for any fundementals wrong. Would be great if you can point me in the right direction.

I have also raised a case with Interwoven on this issue and wanted raise it with a broader community to get some ideas.

Cheers,
Yadhu

Find more posts tagged with

Comments

Aryan

Tried copying libeay32.dll to the system32 folder and also tried copying a working version of iw_cgi_wrapper.cgi and that also did not do the trick....

Any suggestions?

Should all the dll files from \shareddll be copied to system32 folder?

Aryan

I just tested and the workflow part of the issue seems to be resolved. I "thought" i had a good copy of CGI wrapper but i did not. So I copied the "working" version of the CGI wrapper and it works now.

So to get the workflow impersonation working I had to do the following:
1. Copy libeay32 from iw-home\bin to system32
2. Make sure the iw_cgi_wrapper.cgi is not corrupt.

The templating impersonation part of it still remains unanswered. However I have made the impersonation attribute false in the iwutild.cfg to get it working for now.

Copying of lilbeay32.dll has caused other problems for me. My perl programs (Custom menu items) which are invoked from UI have become exorbitantly slow. Dont understand why. Perl programs running in the background are fine (External task programs are running as usual)

Other pieces of information:
1. Please note that i did NOT replace libeay32.dll in system32 folder. It was not over there on the first place. Which is very strange.
2. Are there other DLL files required by TeamSite missing in system32?
3. I did not do installation using built-in administrator account since ours is a hosted environment and the vendor would not enable that account. So I installed it using another user who has all the required admin rights.

Any pointers?

Aryan

Ignore all my previous findings.

It does not work for users who are not a part of the administrators group on the OS which hosts the teamsite installation. I realized that I was continuously testing with my own user id making myself master or editor for testing. What I did not realize is that I am still a part of the administrator group in the OS. And that’s the reason it was succeeding for me even when I was an editor.

So it does not matter whether the DLL is in the system32 folder or not, it does not work.

Aryan

I made another test today and found that you need to add all the users domain users accessing teamsite to "Allow Local Log on Properties" list. Otherwise impersonation does not work.

This was the root cause of the isssue.

I am in the process of verifying with Interwoven whether the solution put in place is the correct one or not.

Shivangi Malot

I am facing v similar issue of workflow task impersonation, i am at windows 2008 64bit OS with Teamsite 7.2.1.

Can you tell me how do i do following suggestion by you.
Is that something to be done in administration tab for roles? Plz help.

"I made another test today and found that you need to add all the users domain users accessing teamsite to "Allow Local Log on Properties" list. Otherwise impersonation does not work.
"

Also let me know the findings .

DashboardPopup.zip

Adam Stoller

I am facing v similar issue of workflow task impersonation, i am at windows 2008 64bit OS with Teamsite 7.2.1.

Can you tell me how do i do following suggestion by you.
Is that something to be done in administration tab for roles? Plz help.

"I made another test today and found that you need to add all the users domain users accessing teamsite to "Allow Local Log on Properties" list. Otherwise impersonation does not work.
"

Also let me know the findings .

No - The logon locally attribute is a Windows OS Administration Policy setting. Most SysAdmins will probably tell you to take a hike rather than granting it, but ...

Aryan

hi... locally logon properties can be changed by Start->Run and type gpedit.msc. Go to Computer Configurations\Windows Settings\Security Settings\Local Policies\user Rights Assignment\Allow log on locally.

As I said before I have taken this solution up with INterwoven on whether this is indeed the right way to proceed or is there a fundamental mistake with the environment.

Once I get more information from them, I will post it. Until then this is the workaround I have implemented by going through some forum posts.

@adam: "Most SysAdmins will probably tell you to take a hike rather than granting it, but ...". You seemed to have stopped it there... Are you saying that this indeed might be the solution.

Cheers.

Adam Stoller

@adam: "Most SysAdmins will probably tell you to take a hike rather than granting it, but ...". You seemed to have stopped it there... Are you saying that this indeed might be the solution.

I'm saying it *might* be the "solution", but that it *might* not be accepted (by your organization's system administrators) as something they're willing to allow.

What's strange (to me) is that I believe that the impersonation aspects *used* to work without requiring log-on-locally privileges - but that could be faulty memory.

Windows can be a royal pain sometimes [always?] - It's one of the reasons I prefer working on Unix with OS-Users, however you don't always get to choose your environment...

Aryan

Totally agree
Cheers.

example.docx

iwovkash

Hello,

Any further updates on this problem. Stuck with the same thing.

Thanks.
TS 6.7.1 SP1 || OD 6.2.1 || Windows 2k3 server OS SP2

Aryan

The only solution I have for now is what i have stated above. That is to add users to the "locally logon properties"

locally logon properties can be changed by Start->Run and type gpedit.msc. Go to Computer Configurations\Windows Settings\Security Settings\Local Policies\user Rights Assignment\Allow log on locally.

The case is still open with INterwoven.

iwovkash

I am still using TS 6.7.1 SP1 and windows 2k3 server OS . Do you remember any specific setting that made this thing work fine for you before.
All my workflow tasks belong to iw_user and that should be sufficient usually. However, this fails to work on 6.7.1 SP1 too.

Thanks.

Aryan

When i checked the setting of my old installations which is 6.7.1 SP1 on one machine and 6.7.2 on another, they also have all the users added to locallly log on properties.

iwovkash

Hello Aryan,

Did support get back to you on this problem. Pretty sure that the custom perl/CGI script execution (in workflows and through API) on the TS server causes all files to be modified by SYSTEM. I tried adding the users to the log on locally attribute as well but it doesnt work for me.

Thanks.

Aryan

Support did not share anything specific and hence I went ahead with this solution..

Can you attach screen shot of the group you added the users to and also tell me how you got there?