I assume you aren't using external authentication, the query above is about people with ID's and passwords actually stored in Remedy, right?
Correct. I didn't set it up but I don't see any LDAP or external auth system configured. All I see is User Password Management Configuration in the AR System Admin Console. I don't see a setting or anything similar to "user attempts timeout".
is the 'Cross Reference Blank Passwords' checked in the server config, and if you look at the user accounts, are there values in the password field, or are they blank?
'Cross Reference Blank Passwords' is NOT checked. And in the User form, the passwords are filled in.
Ok...so, I started searching the online docs and found this page, with this text
"The operating system password management system can also be configured to lock out users after too many failed password attempts"
This discusses the specific ability to lock out when using external authentication...which you are saying you aren't using...
Following those links I get to
Max Number of Password Attempts
Specifies the maximum number of consecutive bad password attempts a user is allowed. If you enter 3, the user has 3 chances to log on. If all 3 attempts have bad passwords, the user account is marked INVALID. Values for this field are 0 (turns features off) and all positive integers. This option can also be set with the AR System Configuration Generic UI form.
Reading further through a few different pages we get to this Error Message
User account locked out due to too many bad password attempts.
Consecutive login attempts failed because of invalid passwords. The AR System server administrator can configure the number of attempts to allow. To unlock your account, reset your password or contact your administrator.
To ensure that this error message appears instead of error 623, set the following parameters in theAR System Configuration Generic UI form.
So...nowhere in this documentation does it state that it's 'consecutive attempts within 5 min's'....just 'consecutive'...which should mean you can try, in the default settings 3 times over 2 weeks and have it still lock out your account...
The only process that I'm familiar with that allows a 'time' between to make a difference is when dealing with Active Directory, or something similar...I know that can be configured for such things....but I see nowhere in Remedy where that is documented, or configurable....so, essentially, I've come to the same conclusion as you...so, if you want/expect any further explanation, it'll hafta come from BMC themselves
Wow! I am sincerely in your debt with this research. Thank you! This is very helpful, especially for others who may need this information, for I did not see this specific topic of login attempt timeout discussed anywhere here.
That makes sense what' you're saying about AD, in that managing a timeout with external auth would be possible and/or such a system may provide it out-of-the-box. But, in this scenario, it's all Remedy. I gather such a timeout feature is undocumented or, perhaps, its value is statically compiled and thus not (easily) configurable.
As I stated earlier, in my testing, after about 30 minutes of idle, a subsequent attempt did not lock me out (this was after 9 failed attempts). I want to try again to confirm that is the case but that's what I observed. Let's say the timeout is 20 minutes. Is that tied to my system configuration? Or, is it universal for all system configurations? Maybe BMC themselves would know.
One theory I had, at least with regards to Mid-Tier: The servlet container conventionally and implicitly instantiates a session on any page it serves up, including the login page. This is before the user logs into Mid-Tier. Now, maybe the login attempts timeout comes from the Mid-Tier session timeout value. E.g,, Mid-Tier session timeout is 20 minutes (for when user is idle), which means login attempts timeout is also 20 minutes.
The user accesses his computer for the first time that day, meaning he has not tried to log into Remedy Mid-Tier. On the very first failed attempt, the system reads the mid-tier session timeout value of 20 minutes and denotes that as the login attempts timeout value, as well. The system sets a timer and if the user tries to log in a total of 10 times before that timer passes the threshold value of 20 minutes, the user's Remedy account is locked out. And it wouldn't matter if the user tried 4 times in IE and then 6 times in Chrome -- Remedy would only denote the first time the user attempted to log in, regardless of the browser. It wouldn't reset just because the user switched to another browser.
I could test out this theory by changing the Mid-Tier session timeout value and observing if the user attempt timeout also changes and report my findings here.
one other thing for you...in the user_cache table in the DB, there are two columns 'badPwd' and 'badPwdTotal'....I don't see either column documented in BMC's docs, but, they seem like they might be related to this topic ....I tried failing my own login a few times (we are using AREA)...but it didn't increment any of my counters...so, I'm not sure how they are used, but...it would then seem that flushing the cache (arreload) would clear any bad password attempts
Wow! This is really great! Thank you. I think this could be very helpful.
I tried logging in 3 times with a particular user. Then, I went to this table and the 'badPwd' field showed the value of 3.
There is the License Review Vendor Form which, as you may know, shows some of the same fields as this table. Could this be what that Vendor Form is referencing and not a local cache on the AR server?
I see at least a few different tables with '_cache' appended to the end of the table name. Would you know if this is how Remedy manages its cache or is user_cache just a backup that it periodically refreshes with a local copy in memory? I suppose I can test it by flushing the cache and observing if the table clears out. This table can be very useful, if it's reliable data.
I still don't see a timeout column in user_cache. Maybe it's located in another '_cache' table.
I am opening up a ticket with BMC. I'm not sure how much help they will be. Even if they know the answer, I have a feeling they might deflect and not want to give out that information.
Thanks for your help with this. This is so great!
If I can use this user_cache table, that means I may not have to use a Remedy API or anything like that to detect if a user is locked out. This table might be able to do the job for me, with the columns of 'licType', 'licTypeFText', and 'licTypeReserv1'.
Actually, it appears those three columns won't be helpful. I compared a good user with a locked-out user and those those three columns have the same values. The only thing of note is the 'password' column value changes to 'INVALID' for the locked-out user. I tried logging in with the locked-out user, with password 'INVALID', and the system does not log the user in. That makes sense because the user password is hashed for comparative operations.
Again, I don't know how reliable or safe this user_cache table is but, so far, it's promising.
There is a 'timestamp' column, too. It looks like it changes based on certain conditions met. One is the 'timestamp' value updates when the user account gets locked and when the user account is unlocked. I have to experiment and observe what happens to it after a few bad login attempts, sit idle for some time, and observe if the `timestamp` column value changes.
And upon researching how Remedy caching works (Remedy 7.6.04 Midtier Cache Explanation), it would seem it's not black-and-white. It offloads cache to files and the database. So I guess for things like forms and workflow, those are kept in memory and periodically refreshed from files and/or the database. But for things like user settings, licensing, basically administrative settings, it looks like some or all those settings are committed to files and/or the database immediately. There shouldn't be a large gap of time between the cache copy and the fetched copy for some object. if my reasoning is correct, that would mean this user_cache table is immediately updated and therefore safe for development use.
I waited over an hour between the 9th attempted login and the 10th one. Unfortunately, on the 10th try, the system locked out the user. I may have to keep experimenting, maybe wait 24 hours after the 9th try and then test again. Maybe when I tried it earlier (before I started this discussion), the cache was flushed. So, I'll have to wait it out and observe. The 'timestamp' column value did not change at all in that hour span. It immediately updated when the user got locked out, which is consistent.
And I don't think any of those objects in the /cache/ folder will contain information pertaining to this discussion, just a guess. Those files seem to be focused on forms, workflow, things like that.
Maybe BMC might say there is no timeout. And if there is one, my guess would be it's stored in a database table or a flat file on the AR server, not the Mid-Tier server. If it's not stored, then it's hard-coded or dynamically created and exists only in memory.
You are going a bit 'all over the place' on this one...let me try and help you stay focused
Ignore Mid-Tier....you can't control a lockout procedure based on method of user access, so Mid-Tier cannot possibly have anything to do with the lockout...so it's not dependent on your browser, which mid-tier you are connected to, etc...it's not client based...so, you can stop thinking about anything along those lines.
Secondly...it can't really be coordinated on the App server (directly anyway) because of server groups, you can't keep it local on each server because then each server would have its own copy of how many times your login failed, which wouldn't be very eloquent. It also can't be stored in memory of the server either, because if that was true, it would be lost upon a server restart...which it isn't...so, that can't be the case.
So, the only place that's common to ALL connections, even across servers is the DB.
Now, go give you a bit more information about the user_cache table. it is kind of a copy of the user form, and kind of NOT a copy....so, any time a record is updated in the user form, the cache copy is created/updated/deleted as appropriate.
All actions taken from an authorization perspective are handled via the user cache, not the actual user form...so, the two are kept pretty close to in sync...but, sometimes things can get out of sync, and in those cases, BMC provides the arcache utility to allow you to reload the cache from the table in question. The cache is not regenerated automatically other than record by record..
So...from that perspective, yes, the cache table is pretty accurate. I've never noticed that a locked out account has its password set to INVALID...that's good to know...I'll file that in the memory banks for future reference
I appreciate it your commitment and trying to narrow my focus. Thank you. I'm also trying to document my progress for others to read, in case they run into this issue, too.
So, you would say Mid-Tier doesn't keep a copy of the User form structure and its data in the /cache/ folder on the Mid-Tier server, is that fair to say?
I do appreciate the explanation. It's helpful and gives me relief that I may exercise the user_cache table.
It can be a little confusing ( to me). I don't quite understand every little thing the Remedy cache is doing. And not all Remedy forms have a '_cache' table. But I gather both AR Server and Mid-Tier must use caching for quick data lookups for some things.
If there is any new progress, I will update it here.
Thank you so much for your help.
And just to clarify because I admittedly bounce around. 'INVALID' is what's stored in the 'password' column. That column, as you know, is designed for hashed values. I don't know what value is set for the Password field on the User form itself, however.
Yes, the Mid-Tier caches things such as form definitions, and active link definitions, but doesn't to the best of my knowledge cache data such as the user_cache.
The Remedy Server itself caches all workflow definitions in memory, and I'm sure some level of Group and User (although I'm not privy to exactly what)