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; } } }

Authentication problems

felipel

(Running Teamsite 5.0.2 in a 2-server clustered Windows 2000 environment)

Just curious if anyone else has run into authentication problems within Teamsite. We've opened a case with Interwoven, but aren't making much progress. The symptoms of what we see are listed in this KB article: https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=2185 (unfortunately the workaround listed there is unclear and doesn't work).

We've boiled the problem down to this: Teamsite caches security information in 10 minute intervals. So, every 10 minutes it requests security information from the Windows domain controller. We've discovered that periodically (perhaps once or twice a day) that request will fail (specifically, the ShowMbrs request fails). Teamsite then caches empty security, meaning that every user action fails because it doesn't think they have security. So, for 10 minutes, Teamsite is essentially unusable--after 10 minutes it re-caches the security and everything works fine again.

We've run some network monitoring and when the security calls fail, the Teamsite server isn't even requesting security from the domain controller. So somewhere on the Teamsite server something isn't working correctly. As a workaround, we'd like to be able to set the length of time security is cached as well as be able to force it to re-cache security in the event of a failure.

Has anyone else seen this behavior and been able to fix it or work around it? It's causing a lot of problems for our users when it happens, and we haven't been able to find a resolution. Thanks in advance...

Find more posts tagged with

Comments

Gregg Faus

We are also experiencing intermittent problems described in KB #2185. I can log into TeamSite as Master and can edit files just fine, but when I log in as Admin I cannot edit anything, even though I have permission.

The solution in the KB doesn't really help. Basically it says check your domain controller. Not helpful at all.

Weird thing is, this happened yesterday to me and then all of a sudden it was working fine. Now today again, it is doing the same thing. Users cannot edit files!

(FYI, running similar environment, Win2k, TS5.5.2)

felipel

Yes, you're describing the same symptoms as us. Apparently when you're logged in as a Master it doesn't do the same authentication checks it does for everyone else--so you're able to continue working.

It's extremely difficult to troubleshoot since it's intermittent. However, I bet you'll find that it never last longer than 10 minutes (unless you get the unfortunate situation where the security request fails multiple times in a row). That's about the only consolation...

Gregg Faus

Yup. The problem goes away suddenly and then reappears some time later.

I just want to make it clear that I don't think this is a product related issue, more of an issue with our Active Directory. Just that there are no docs to show how to troubleshoot basic problems. We did a firewall upgrade this weekend and I think that is effecting our directory.

felipel

I would agree that the root cause is probably an Active Directory issue (although we opened up a case with Microsoft and they claim otherwise). I think there's still product issues with Teamsite, however, in the fact that it accepts a failed security request without logging or re-trying or providing any mechanism to work around the problem.

Gregg Faus

True. There is no way to determine the root cause of failed security request. In fact, I find that the documentation related to AD integration is quite inadequate.

On a related note, I'm experiencing problems where administrators cannot apply permissions to files (via explorer or command line) in certain workareas. For instance, I have a workarea called client under a branch (let's call it project1). I can give full access permissions to the directories contained under "client" workarea, but it will give me an access denied to the files.

So if I would run "cacls y:\default\main\project1\WORKAREA\client\ /t /e /c /g domain\project1" from the command line, the directories will accept the ACL change, but NOT files (get the ACCESS denied error).

Another thing is if I create a new workarea under this same branch, the group I share it with doesn't seem to propogate to all the files either.

Anyway, thought I'd share that if anyone has feedback. I'm thinking it still relates to the AD issues.

FYI. This thread should probably be in the Content Mgmt topic. Oh well.

JamJamT

Any of these systems just recently upgraded to AD or perhaps a change in domain name? We ran into similar authentication failures regarding these changes. I don't know if your authentication problems are related or not though ....

Adam Stoller

What style of TeamSite locking is on the branch where you cannot set the ACLs on the files? the default "Submit Locking" or one of the alternatives like "Mandatory Write Locking"?

If it's the latter, that might explain things (just a guess)

--fish
(Interwoven, Curriculum Development)

Gregg Faus

We have not done anything with AD recently, just that we upgraded to a F5 firewall. There were some network access problems, but I think they are resolved now.

This particular branch has mandatory write locking enabled. What is the correlation between the locking model and ACL's? I've tried auditing the workarea in question, but have yet to produce a failed permission change entry in the security log. This mounted drive can still be audited I hope.

Adam Stoller

If it's mandatory write locking - the files are read-only until/unless locked - and thus the IFS may be preventing you from setting ACLs on the files while they're in that read-only state.

Since directories aren't versioned as distinct entities in TeamSite - they probably aren't being treated as read-only, and thus you've been able to set the ACLs on them.

This is purely guess work on my part - but it would seem to fit the scenario.

Suggestion - try setting the ACLs on a specific file within the workarea (un-locked). Then try locking the file within the workarea (through the GUI or using the 'iwlock' CLT) - and then try the same ACL setting operation - see what happens.

--fish
(Interwoven, Curriculum Development)

Edited by ghoti on 09/19/02 09:00 AM (server time).

Gregg Faus

Yes. That worked. I locked a file and then added the group just fine. Now I just have to figure out how to lock all 500 files in an efficient manor so I can apply the ACL. This directory by directory locking is a pain. Anyone have a recursive locking script?

Thanks ghoti!

Adam Stoller

If you are comfortable with Perl programming you could use File::Find to recurse through the directories, the iwlock CLT to lock the files, and even problem a Win32 or Win32API module to do the ACL settings - on in one script...

But no, I don't have such a script handy - sorry.

--fish
(Interwoven, Curriculum Development)

tvaughan

This problem happens on Solaris as well. We were configured to use Novell's NDS LDAP implementation. Every once in a while a "hiccup" in the LDAP connection would cause TeamSite to "lose roles."

Basically, no matter who you were, you couldn't get in to TeamSite because your role authentication was rejected. Looking in the iwtrace.log would show that every 10 minutes, TeamSite would try to re-read all the *.uid files and fail!

It sounds like you Windows people have it a little better because at least your authentication comes back after 10 minutes. Once you get in to this "lost roles" condition in Solaris, you have to bounce the server.

Our solution was to (surprise!) upgrade to TeamSite 5.5.2.

Tom