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

Invalid login

Maninder_IBM

We have this problem almost every month! Here's why! When users are prompted to change their password every month on the operating system this then locks out teamsite users.

Sometimes rebuilding the specific db entity or the whole lot, or deleting cookies etc solves the problem,

At the moment we users that still can't get in, is there anything else I should be trying?

And more importantly why the **** is this happening?

Find more posts tagged with

Comments

Adam Stoller

How soon after the users change their passwords are they trying to login to TeamSite?
How do you have TeamSite configured for authentication?

As a guess - wherever TeamSite is directing the requests for authentication has not been updated at the time the user goes to login.

I'm far from an expert in this area, but I think if you could find a good network person who can set up packet sniffing of some sort on the TeamSite server, they might be able to trace the direction of the request/response to help figure out where the problem is coming from.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Bowker

I had a similar issue. I would, on occasion, be signed in on two workstations when I changed my password and that would cause all sorts of issues.

The other issue is that (from what I can tell) TeamSite keeps revalidating the password when you do stuff. If you change your password, while still logged in to TS you will lock the id on the LAN (We're in a windows environment). Make sure that after the password is changed (or better before) that all teamsite/opendeploy sessions are logged out and ALL browser windows are closed.

Good luck.

Maninder_IBM

Well, windows users are reminded in the morning when they attempt to log on to change their password. So they do and proceed to log on. They could try to log on to TeamSite immediately, or wait a day or say even. Users are authenticated with their network logon. I thought the fact the users may still be logged into teamsite after they have changed their password maybe causing the problem. Currently I have one user who can't get in.. even after rebuilding the entities DB. Does that mean user and password information os stored elsewhere too?

Bowker

Everyone has their own processes for stuff like this - this is ours: (You will have to change the pathing on the commands, but you get the idea.)

0) reboot the box! (this must occur before you start this process or it will not work)
1) telnet in to TeamSite box and issue these commands:
> iwperl e:\apps\interwoven\teamsite\bin\iwrmuser.ipl -V username (username is domain\id)
2) Wait 10 minutes (Don't sign out of the TeamSite box yet)
3) Put the username back into the necessary roles files (e:\apps\interwoven\teamsite\conf\roles\author.uid, ...\editor.uid, .. etc)
4) Issue this command in your telnet session:
> iwreset
5) Wait 5 minutes and try to sign back on.

it is VERY important that the user NOT try to sign in between the reboot and after step 5 is completed.

Maninder_IBM

This is our procedure and I have already tried it. This one is certainly bugging me!

CD to iw-home\bin
Type iwrmuser.ipl domain\username (iwrmuser.ipl interwoven\jdoe)
Type iwckrole role username (iwckrole author interwoven\jdoe)
This should return "NO"
If anything but "NO" is returned, wait 10 minutes, re-run iwckrole
If anything but "NO" is returned, re-run iwrmuser.ipl and repeat the above steps until "NO" is returned. This scenario occurs when there are multiple entries in the entities database for the same user.
After "NO" is returned, proceed to the following:
Type iwadduser.ipl -user username -roles role (iwadduser.ipl -user interwoven\jdoe -roles author (You can use CSV here (author,editor)))
Type iwckrole role username (iwckrole author interwoven\jdoe)
This should return "YES"
If anything but "YES" is returned, wait 10 minutes, re-run iwckrole
If anything but "YES" is returned, re-run iwadduser.ipl and repeat the above steps until "YES" is returned.
Try to login

exemple.docx

Maninder_IBM

Mind you I haven't done an iwreset after though.. I wonder if that is it?

Am I right in saying that this is removing duplicates entries in the roles file only?

Bowker

I don't know about removing duplicates but it does effectively remove the user and some of their preferences including home page within TeamSite. In our site that's important. It may also remove favorites for webdesk users, but we don't use webdesk.

The only other thing you may want to try (this is a pain but...) is to reboot the system. We have 4 (exactly 4) users who about once a week can't sign in. In the middle of the day they will just get an error that their password is invalid. The only way to fix them (that we have come up with) are the instructions posted earlier.

Maninder_IBM

We did reboot last night after rebuilding the entity DB. It's a pain in the **** init!

nipper

Have you filed a bug on this ? It happens here way too often as well. We file a bug, cleanup reboot, etc, & the bug get closed.

That specific problem goes away, but the basic problem, still exists and I really don't think IW is paying much attention to it since there is a workaround.

As if rebooting a server used by 200 users is an acceptable workaround.

#FLAMEOFF

Andy

Maninder_IBM

Absolutely. I agree. We have nearly 200 users. We can't reboot the server just like that. I don't think IW have found the underlying reason. I have logged a case with them to find out the underlying reason. It's reoccurrence is unacceptable. In this case we haven't even found a solution yet so let's see what they say. I'll keep you posted, in the mean time if anyone knows anything else I can try please let me know!

ORDER_DESCRIPTION.ssd.zip

24938.pdf

Migrateduser

TeamSite, by default, caches credentials, so password changes do not take effect until the cache is updated. This happens automatically every 10 minutes or so. You can also force a cache update to take place immediately with an "iwreset" command.

Credential caching can be turned off completely, so password changes take effect immediately, by setting
"enable_cache=no" in the "[iwserver]" section of "iw.cfg'.

Disabling caching may slow down logins slightly, but in most cases, the difference won't be noticeable.

(Note: These comments apply to TeamSite on Solaris or AI/X only. TeamSite doesn't use do this kind of caching on Windows.)

Al Borr
Interwoven Engineering

nipper

>This happens automatically every 10 minutes or so. You can
>also force a cache update to take place immediately with
>an "iwreset" command.

supposed to and actually does are 2 very different things. If it worked like you say, we would not be complaining.
& yes many support cases have been opened.

Maninder_IBM

I must have forgot to mention we user windows.

So, are you saying that if you use windows deleting the users cache won't make any difference as this info isn't cached? So how come I have been told to clear the cache? Surely interwoven engineers knew we use windows as I have told them.

Maninder_IBM

Currently all users able to get in. But I have a case open for the reoccurrence of this happening. Hopefully well get a rapid response from them!

Aborr isn't there anything like you mentioned from Windows.

Migrateduser

For TeamSite on Windows, we rely on Microsoft's native user authentication code and do not run our own authentication routines. Password expiration, updating, etc. is managed by Windows, completely outside of TeamSite. Windows determines what password is accepted when.

If a user's Windows password is changed while he is using TeamSite, TeamSite will present a login page the next time he tries to do an operation that requires authorization.

I don't see a lot of problems at login time on Windows. Those I do see tend to have exotic causes, such as a faulty migration of users from an NT/4 domain to an AD domain.

Al Borr
Interwoven Engineering

ORDER_DESCRIPTION.png

Bowker

Al -

I have an open case with IWOV now about just this issue. I STRONGLY suspect that the root cause for exactly four of my users is a bad migration from NT/4 domain to AD domain. What can I look at to see if that is the cause. What exactly causes a faulty migration.

THANKS
Dan Bowker

Maninder_IBM

With us windows manages all passwords. But the network passwords are set to expire every month and the user is prompted to change their password when they log in to the network. Then when they try to log into TeamSite (no matter how long after) they are denies access to TeamSite. As TeamSite uses windows authentication it doesn't seem to pick this up in TeamSite. Then we are forced to rebuild the entities DB etc etc....

ConnectionSettingsAndError.zip

IanP

Just to add you're not the only ones I had the same issue on 552 windows. I used combination of processes mentioned in the thread. Essentially:
iwrmuser
add the user back to the uid files
iwreset, wait 5 mins and iwckrole repeat until response 'yes'

Migrateduser

"if you could find a good network person who can set up packet sniffing of some sort on the TeamSite server, they might be able to trace the direction of the request/response to help figure out where the problem is coming from."

Excuse me, but this is clearly Interwovens Job.

-r

Adam Stoller

If you could find a good network person who can set up packet sniffing of some sort on the TeamSite Server, they might be able to trace the direction of the request/response to help figure out where the problem is coming from."

Excuse yourself - Interwoven is not in control of every single customer's network environment - the individual customers are (or in some cases a 3rd party service organization) - as such - doing something like this to track down the source of the problem is the responsibility of the customer - with the possible exception of a customer using an Interwoven Consultant, and even then....

Case in point - a customer I am working for right now had a problem earlier today where some users could not seem to login to TeamSite using the LDAP passwords, but others could, and some of those who could not login with their LDAP passwords could login with local unix account passwords. The problem was apparently that one of their load-balanced LDAP servers was operating slowly and causing timeouts.

Why would you expect determining that to be Interwoven's Job?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

jbonifaci

Wow, what a pleasant response to a post that is almost a year old, Smiley Happy

. And he felt strongly enough that he made this his first post ever on devnet (at least under this user name). Doesn't that just make your day fish? Smiley Wink

nipper

Yea, esp since all the complaining has stopped.

I was one of the ones with a problem like this. One problem login. I ended up
making a local account (with password) for this user and not using LDAP. Works
great.

I parsed thousands of lines of TS and LDAP error logs & came up with nothing.