Alex VanderWoude

If a password list has its "Hide Passwords from users with the following permissions" property set, and you then log on as a user that has insufficient permissions, the passwords on that password list show the little mask icon as you'd expect. If you hover over it a popup message appears: I believe this message should be:

Ah, excellent, thanks very much. That will save some time, and because it is in the Administration tab you have to be quite privileged to even try to do it.

Is it possible to delete a folder and all its contents in one go, or must I manually delete every item inside a folder before the folder itself can be removed? While experimenting with some things, I created a folder with a bunch of temporary sub-folders and password lists that did not actually contain any passwords. Now that it is time to clean up, I find that I must delete each item individually, and slowly work my way back up the tree. Is there a "nuke this folder and everything that is inside it" option? I realize that this functionality could be dangerous indeed, like "rm -rf" on a Linux system. So if it turns out there is no such ability in Passwordstate, I will not be entirely surprised...

I found the option: As soon as I enabled "Allow Password List to be Exported", the option was enabled on the dropdown list. Thanks very much! You know, this might be a pretty good item to have in the FAQ. Something like: "How can I export my password list when the option to do that is disabled?" And then describe the various things that might be causing that.

I want to export all the passwords from a particular password list, so I navigated to that password list and used the "List Administrator Actions..." dropdown to select the "Export All Passwords" item. Sadly, it is disabled: I poked around to see if I could figure out what is disabling that item. First I ensured that the user I'm logged in as has admin rights on that password list. Here is that list's permissions: As can be seen, that's me at the top of the list of admins. Next I looked at Administration > System Settings > password list options: Looks like that is set to allow exports. So what is causing that item to be disabled? Is there some other setting that could be interfering here? If it helps, we're using build 9381.

I tried the report with the "Export to Excel (97 - 2003)" link instead, and after quite a long time (10 minutes or more) that eventually timed out. The error console contained this: Build No '9381' - Request timed out., StackTrace = So I'm afraid that also does not work.

I ran the "What permissions exist for all shared password records (enumerated permissions report)?" on our site, which took a while and produced a set of 123282 items. I then attempted to export that report as an Excel file using the "Export to Excel" link. Eventually an error was produced, and the Error Log showed this: Build No '9381' - We found a problem with this formula. Try clicking Insert Function on the Formulas tab to fix it. Not trying to type a formula? When the first character is an equal (=) or minus (-) sign, RadSpreadsheet thinks it is a formula. For example, when you type =1+1 the cell shows 2., StackTrace = at Telerik.Windows.Documents.Spreadsheet.Model.CellValueFactory.Create(String value, Worksheet worksheet, Int32 rowIndex, Int32 columnIndex, CellValueFormat currentFormatValue, ICellValue& cellValue, CellValueFormat& newFormatValue) at Telerik.Windows.Documents.Spreadsheet.Model.CellSelection.CreateValue(String value, ICellValue& cellValue, CellValueFormat& newFormat) at Telerik.Web.UI.ExportInfrastructure.XlsxRenderer.SetCellValue(CellSelection xlsCell, Cell cell) at Telerik.Web.UI.ExportInfrastructure.XlsxRenderer.CreateWorksheet(Table tbl, Workbook wb) at Telerik.Web.UI.ExportInfrastructure.XlsxRenderer.CreateWorkbook() at Telerik.Web.UI.ExportInfrastructure.XlsxRenderer.Render(Workbook workbook) at Telerik.Web.UI.Grid.Export.TableViewExporter.ExcelExportRenderForm(HtmlTextWriter nullWriter, Control form) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.HtmlControls.HtmlForm.RenderChildren(HtmlTextWriter writer) at System.Web.UI.HtmlControls.HtmlContainerControl.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter) at System.Web.UI.HtmlControls.HtmlForm.RenderControl(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Page.Render(HtmlTextWriter writer) at System.Web.UI.Adapters.ControlAdapter.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter) at Telerik.Web.UI.RadAjaxControl.RenderPageInAjaxMode(HtmlTextWriter writer, Control page) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Page.Render(HtmlTextWriter writer) at System.Web.UI.Adapters.ControlAdapter.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter) at Telerik.Web.UI.RadAjaxControl.RenderPageInAjaxMode(HtmlTextWriter writer, Control page) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Page.Render(HtmlTextWriter writer) at System.Web.UI.Adapters.ControlAdapter.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) No idea what formula it is talking about, but I suspect that's a bogus error. My suspicion is that the sheer volume of items is causing the trouble. After the report had been retrieved, I filtered it down to a mere 46000 items and attempted the export again. This time it succeeded, which supports my suspicion that the number of items is too much for the code (or memory?) to handle. Any ideas? This is not really critical for me, so if it never gets resolved I'll just shrug and move on. But it would be nice to have it fixed.

I think there may still be a problem with this functionality, even in build 9381. When the lower-down item disables inheritance of permissions and then removes an entire security group (for example, SecGroupXYZ) from its permissions, and then unchecks "Disable Inheritance..." so that it once again inherits permissions, the following happens: SecGroupXYZ does not show up in lower folder's permissions, as explained earlier in this thread. Go to upper folder and change its permissions for that group, such as setting SecGroupXYZ to "View". Go to lower folder and look at its permissions. SecGroupXYZ still does not appear in the list, alas. If a group (for example, secGroupABC) appears on the permissions of both upper and lower folders, then changing the upper folder's permissions is propagated down to the lower folder as explained earlier in this thread. If SecGroupXYZ is removed from upper folder, and then re-added to upper folder, only then does it also appear in lower folder's permissions. So it seems that when inheritance of permissions is re-enabled (a fairly unusual thing, I will admit), there isn't a full synchronization occurring on the next permissions change. Specifically, when a group exists in upper folder but not in lower folder (due to fiddling around when permission inheritance was disabled), it is not re-added to lower folder when a mere change is made -- even if that change is in the group that is missing from lower folder. Only by removing and re-adding that group to upper folder does the system also ensure it is added to all the child items.

Okay, thanks for confirming that. It looks like we'll have to be very stern when we tell the users we assign as admins that although they CAN block support from having access to their folders, they really really should not do that. Or there will be smiting and furious wrath!

At our site we'd like to make different sections of the company have different folders and sub-folders that they administer themselves. However, as you might expect, our internal IT support wants to always have admin access on everything. After all, if something goes wrong, who's going to be called? Now in v9 we can certainly assign anybody we like to be admins of sub-folders, so that takes care of the first requirement. The danger is that those people could then remove the IT security group from their sub-folder's privileges. They probably wouldn't, and we'd tell them not to do that, but the system would not prevent that from happening. Is there a concept of a root user or a superuser in Passwordstate? Some one (or someones) who have total access to everything and cannot be excluded? (Other than viewing private password lists, of course.) I had thought that maybe Security Administrators were such users, but that does not seem to be the intent of those.

In the v9 Security Administrators Manual, in the section "User Account Actions Menu" there is the following note: I think this text is ambiguous. It seems to be implying that the act of disabling a user account had no effect on your count of licenses used. But this is obviously nonsense, only enabled users are counted when determining how many licenses are being used. I suggest something like this: "Note 2: When a user's account has been disabled, it no longer counts towards the number of licenses used. In other words, only enabled users are counted when determining how many licenses are being used."

Well, I looked carefully in the IIS log files again, and now that I'm not hyperventilating I can see that the calls are indeed being done once per minute, not once per second. I am rather shame-faced about my earlier assertion! So it looks like the Browser Extension is doing a heartbeat/refresh sort of thing, and I suppose this is perfectly normal. And since it is happening only once per minute (well, eight calls at the beginning of each minute), it's not exactly a DOS attack. I will have to look into this browser extension and see what that's all about. It makes me wonder why this is showing up on that one guy's machine, but nobody else's. Presumably he's the only one who has it installed.

Here's an update on this issue. It has not yet been resolved, but I have a better idea of what is going on. Since we are using SQL Server Express, we do not have auditing data available to us. But your tip about looking in the IIS logs was very helpful, I found some good stuff in there. It turns out that the SAML authentication errors correspond exactly with login calls coming from one of our Rapid7 scan engines. Clearly something needs to be updated in our Rapid7 configuration, and we're working on that. This wasn't seen before because we have been using SAML2 authentication only as of last week Thursday, when we cut over to the new server. Another thing I spotted while reading the IIS logs is that one of my colleagues' laptops was issuing POST calls to Passwordstate like these: /api/browserextension/GetPasswordGenerators/ /api/browserextension/GetIgnoredURLs/ /api/browserextension/getpasswordlists/ /api/browserextension/getwebsites/ Every single second it would issue eight calls, and this went on from about 9:20AM to 00:46AM the next morning! So it looks like there's some sort of script or something running on that laptop? My colleague says he has no idea what it might be, he's not even using Passwordstate to his knowledge. We're going to be looking in to that later today. But if this sounds familiar to you, please let me know!

Recently I moved our Passwordstate system to a new server, and upgraded it to build 9360 at the same time. Everything seems to be working well, but I have noticed that every evening at about 8:05PM a bunch of error messages are written to the Error Console. Typically there are 16 or 17 of them, and they all occur within the span of one minute. The messages themselves are not very helpful. They all look like this: 2021-11-08 8:06:21 PM,General Error,"Build No '9360' - Error Code = Object reference not set to an instance of an object., StackTrace = at ComponentSpace.SAML2.Data.SessionIDDelegates.BrowserSupportsSameSiteNone(String userAgent) at ComponentSpace.SAML2.Data.SessionIDDelegates.AddSAMLCookie(HttpCookie httpCookie) at ComponentSpace.SAML2.Data.SessionIDDelegates.GetSessionIDFromSAMLCookie() at ComponentSpace.SAML2.Data.AbstractSSOSessionStore.CreateSessionIDForType(Type type) at ComponentSpace.SAML2.Data.InMemorySSOSessionStore.Load(Type type) at ComponentSpace.SAML2.SAMLController.LoadSAMLConfigurationState() at ComponentSpace.SAML2.InternalSAMLServiceProvider..ctor() at ComponentSpace.SAML2.SAMLServiceProvider.InitiateSSO(HttpResponse httpResponse, String relayState, String partnerIdP) at uRM=.XSg=.YCg=()",Error, When I exported the Error Console information to a CSV file, I noticed that there were additional items (two per day) that looked like the following: 2021-11-08 8:06:20 PM,Session Ended,"Build No '' - It appears the user's session in IIS has been prematurely ended, causing the following error - A potentially dangerous Request.Path value was detected from the client (&)., StackTrace = at System.Web.HttpRequest.ValidateInputIfRequiredByConfig() at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)",Session Ended, Note that these did not show up on the Error Console itself, only in the exported file. It seems like there is some kind of scheduled event occurring at 8:05PM, but for the life of me I cannot find anything in the Administration tab. Our daily backups take place at 1:00AM (although now that we're on Daylight Savings Time that occurs at midnight). The AD Security Group sync takes place at about 12:31AM. I cannot find any other scheduled item, but perhaps that is my inexperience showing. There doesn't seem to be any kind of bad result from the above errors, Passwordstate appears to work just fine. But the Error Console list of errors keeps growing, and I'd like to resolve that. Does anyone know what might be going on here?

Ah, I see. I navigated to the Passwords tab, and then to the above two Password Lists. Sure enough, when I select one in the tree, right-click on the selected name, and choose "Edit Properties", the page shows the correct value in the Password Generator Policy field. So it appears that the problem is indeed in the GUI, but only on the Administration > Password Lists side of things. That's good to know, it means I don't have to panic and start changing our existing Password Lists. Thanks for the feedback, and hopefully the fix for this can be added to the next release. After all, how big can your bug list possibly be, right?

I'm not sure how to highlight a Password List except by moving my mouse over it. That makes the background go darker, which I suppose is a highlighting of sorts. But in order to even click on that triangle icon, the mouse is necessarily "over" the row, and thus highlights it. There is no way to click the row and make it have a persistent selection color. Here's what it looks like to me: As you can see, the light colored row is now greyed out, and the icon goes red when my mouse pointer touches it. I can then click on that icon and choose "Edit Password List Properties", and in the page that appears the Password Generator Policy is incorrect as described in my original post. The only thing that is properly highlighted is the "Password Lists" item in the left-most list. Is that what you are talking about? Because if so, I don't see how to not have it highlighted.

I have noticed something odd in both build 9112 and 9350, but I'm not sure if it is something I don't understand or if it is a genuine bug. We have defined a Password Generator Policy named "CX Default Password Policy" that we use on pretty much every Password List (although there are exceptions). The thing is, when I look at such a Password List's Properties page it shows me that the Password Generator Policy is "My Personal Generator Options", not the one we want. If I look in the Passwordstate database, it reports the correct generator policy! So I suspect a bug in the GUI. I used the following query to examine the Password Lists we have defined: select pl.PasswordList, pl.TreePath, case pl.PrivatePasswordList when 1 then 'Private' else 'Shared' end ListType, pg.GeneratorName, plt.PasswordList PasswordListTemplate from dbo.PasswordLists pl left join dbo.PasswordGenerators pg on pg.PasswordGeneratorId = pl.PasswordGeneratorId left join dbo.LinkedPasswordLists lpl on lpl.PasswordListId = pl.PasswordListId left join dbo.PasswordListTemplates plt on plt.PasswordListTemplateId = lpl.PasswordListTemplateId where pl.Folder = 0 -- Only leaf nodes order by lower(pl.PasswordList) Here is a snippet of the output data: In the Passwordstate website when I navigate to Administration > Password Lists, choose the cc-CSP list, and use the little triangle widget to go to the Password List Properties page, the following is displayed: As can be seen, the Password Generator Policy is not displaying "CX Default Password Policy", much to my surprise. Note that cc-CSP is not based on a template, while cc-HEN is. That doesn't seem to make any difference in the behavior I'm wondering about other than changing whether or not the fields on the Properties page are editable. Does anyone have any idea what is going on here? It seems like the GUI is misreporting what is in the database, but perhaps I simply don't understand something. For the record, I attempted to look for existing issues like this on the forums, but I was not able to find any. That makes me suspect that I'm doing something weird, because if this was an actual bug surely somebody would have noticed it before!