Jump to content

cwaters

Members
  • Content Count

    15
  • Joined

  • Last visited

About cwaters

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I agree, the extension swapping isn't ideal, but it would provide a structured and repeatable process for a user to follow if we end up in that situation that would apply equally to all users, regardless of OS. The alternative being they loose the auto-fill functionality until the platform catches up. The group policy only works on windows, which still leaves out the Mac users (like myself) which we estimate to be about 40% of our user population. Thanks again.
  2. I think you're focused on the word beta and not the intent. I'm not suggesting you release a beta version in the store. The beta moniker is just a naming convention that demonstrates that these developers have more than one plugin in the store for the same thing. I can choose to run the beta or the stable. I have the option to control the version in that sense. In the same way if there were 2 different Passwordstate extensions in the store (you could name them anything you wanted), I would have the option to use the current Passwordstate plugin, or the previous. It's just a convention. I find references for the feature to be added for chrome going back to at least 2010. If 9 years of requests with no change means anything, it seems like that will be a loosing battle. If it's not really feasible for you or you just don't like the idea, I get it. I'm not trying to push too hard, I'm just hoping I was able to convey the idea properly. Thanks again.
  3. Below is a random example from the chrome store. Basically, they are 2 separate extensions. You can find a lot of examples by searching for "beta" in the the store, and then redo the search to use the base extension name of one you find. In many cases, you'll see examples like below. Full disclosure that I haven't found anything that says you can/or cannot do this in the store but it seems like a quite a few devs do this. I assume when they are done with beta, the move the code to the non-beta plugin reference. I suggest something similar could be done when you release the latest version, you move the previous version to "-previous" extension. To be clear, I'm just making suggestions and likely don't have full understanding of the processes involve. That said, as a customer, this has the potential to be a very large problem for me so I'm hoping to have something relatively easy for an end user (or 1000) to do if we for some reason can't complete our internal upgrades before a new version of the extension comes out even if it's a temporary, somewhat kludgy work around of (please install the -previous plugin from the store until we complete our internal testing). I see a lot of references to folks asking the same question about how to disable auto-update for extensions in chrome with not much traction. I do appreciate the support and discussion. @Ryan Coyle sorry to hijack your thread.
  4. I put forth a a feature request which was already archived with a similar response. I would say that my suggestion to have a "Latest" and "Previous" version of the plugin available in the stores could have used more consideration Clickstudios. I see in the extension stores where stable and beta versions of plugins are available for many. I don't see a fundamental difference here for my suggestion but Clickstudios said they don't believe the stores allow this. Here's a link to the other thread which I can't reply to https://www.clickstudios.com.au/community/index.php?/topic/2849-browser-extension-multiple-versions/
  5. Hi everyone, I'd like to recommend that previous versions of the browser extension be available in the extension stores. As a company with what will be a fairly large user base, we have the need to have a stable platform where dev/test/prod pipelines and proper change management can take some time. That time may exceed the duration from when a new version of the extension is released to when we can update the backend platform. The impact of having the extension automatically update and become non-functional because the main platform has not be updated is problematic. Perhaps maintain something like this: Passwordstate-Latest Passwordstate-Previous Even if you provide just the last released version (i.e. you don't need to support every previous version, just the last one as this will still help encourage keeping the platform up-to-date) in the stores, we can at least provide a method (tell them to install the previous version) to our users to keep them working easily. It's still not a great user experience, but better than having to expedite platform level updates because of a browser plugin. I'd really like to avoid lots of helpdesk tickets because the auto-population stops working. I'd be open to other solutions as well but I figured I'd at least propose something to start with. Happy to expand on the idea if needed. Thanks.
  6. cwaters

    AzureAD

    Please correct me if I'm wrong but I believe what @AndersB is alluding to is if you want to manage access by using/importing existing security groups from your AD, you can't do that today with AAD even if you are syncing from AD to AAD. AAD is only for the authentication part. If that's not true, I'd love to know what I'm missing.
  7. Glad to see this discussion moving! Just to share the info (though we seem to be past these specifics): To answer the question previously about the HA capabilities of App Gateways in Azure, yes, they are somewhat limited as far as the health checks are concerned. The best way to describe them is "If I see this thing, you're healthy and I can send you traffic." There's no concept of "You're sick, I shouldn't send you traffic." The question about a web node not being able to get to the DB in a region. The DBs are replicated and available across multiple regions and have endpoints in the same regions as the web clusters. It really had to do in our case about DNS resolution. In one region, we lost a tunnel that we talk to our own DNS servers (internal ranges) through. In the other region, that tunnel was up and would have been able to service the requests. Since the web nodes are accessed publicly, the all web nodes showed up to the load balancer in the bad region, but since the region couldn't resolve the DB name, traffic was still being set to a node that couldn't get data. Azure has also recently experienced some DNS related outages for their service so, this scenario is also possible if we were using the "built-in" DNS features from Azure.
  8. We have a high availability setup in Azure for Passwordstate that consists of a Traffic Manager, and 2 sets of App Gateway load balanced clusters in different regions. We have encountered and issue with what happens when the DB is unreachable from a single region. Currently in Azure, the load balancing health checks available only look for "good" HTTP status codes and strings to determine health for the backend pools. In the case of Passwordstate, if one of the redundant servers/clusters behind the load balancing loses the ability to connect to the DB, the webserver still produces a good code, the health probe doesn't fail , and requests are still sent to the available server/cluster. There doesn't seem to be a way in Azure to probe, for example, a 200 webserver code and match a string from the DB error page to have the load balancer trip (again, it only operates on good results for a health check). Any thoughts on how to solve for this? The limitations are in Azure, but I'm wondering if it makes more sense (or can have an option) to throw a true HTTP error code for that condition? A 500 or a 503 (I'd settle for a 418 just to get past this), just something outside of 200-399 range which is the default "good" range for the Azure App Gateways and Traffic Managers. I'm digging into a string match, but as we use SAML and AAD for authentication, the number of redirects makes it difficult to determine what would be a consistent string in a page that won't be on the DB Error page that gets served. This is probably doable but seems like a long way to go. Anyway, appreciate any thoughts here. Thanks.
  9. cwaters

    SAML - UPNs and Email Don't Match

    The format is user@domain. In this case, the domain is is not the same as the email domain. I believe that most of what MS does in this area is here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-federation-saml-idp I found this note on the page: The “UserPrinciplName” value must match the value that you will send for “IDPEmail” in your SAML 2.0 claim and the “ImmutableID” value must match the value sent in your “NameID” assertion. I'll ask my admins how we have this implemented specifically as it may help clarify this. Since I understand the behavior we have a work around, but I'll take a look at these parameters in the Azure AD and see how they would map out.
  10. cwaters

    SAML - UPNs and Email Don't Match

    In our case because we have a hybrid traditional on-premise AD with integration to Azure AD (not an uncommon situation I would wager), UPN still seems like the best fit. I would suggest that the change would be to allow user user to simply change the default for that specific attribute (Name Identifier). That way, if a user doesn't actually have an email address, there is still a value to match against. I'm not sure if that makes sense or not or perhaps I mis-understand how the SAML is supposed to work. We have a work around by adding a bogus email address on the AD side, but it seems like hack. Thanks for the support.
  11. cwaters

    SAML - UPNs and Email Don't Match

    Thanks for the response. I was able to get this to work and it appears it had to actually do with the IIS setting for Anonymous access needing to be enabled. I should have kept better notes on my testing but I believe that was the change that enabled this to work as expected for me. I'll try to test again to confirm that. With SAML 2, is it not the case that you can choose which attributes can be used for the Name Identifier?. Maybe a feature request would be to allow this to be configurable on the Passwordstate side (it is on the Azure SSO side). A current use case is for administrative accounts (generally used for elevated access) that don't have an email address associated with them (in AD as an example). In this case, the UPN would be better than email as an identifier.
  12. cwaters

    Azure MFA Authentication

    Other than needing to login twice, once for AD and once for Radius, you "can" use Azure MFA with a NPS server with the Azure MFA extension installed. You will need to be using the "push" notifications for the Authenticator app but this does work. I tested it today as a matter of fact. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension
  13. Hi everyone, We're trying to take advantage of using SAML with Azure SSO (and Azure MFA) but are encountering some issues with the user mapping. I followed the guide from the Security Admin Manual. Our userprincipalnames don't match our email and that may be part of the issue. SAML is "working" based on the error we get but I'm not sure where to go from here (Error 1). I've also tried re-mapping the SAML token attributes on the Azure SSO side so that the emailaddress was the user.userprincipalname value and various combinations but anything other than the User Identifier as user.userprincipalname and the other defaults for the token fail with an unresolved error (Error 2). Also, I previously set up normal ldaps auth and may be experiencing a conflict in usernames but I'm just not sure. Thoughts/suggestions? Thanks. Error 1: Access Denied User Not Found in Passwordstate It appears your account has successfully authenticate to the SAML Identity Provider, but the email address returned was not found in the Passwordstate database. Below is the email address returned, and you will need to ask you SAML Provider Administrator to ensure the email address recorded for your account in Passwordstate, matches the email address recorded for your account on the SAML Provider's web site. Email Address nobody@redacted.upn <--this was a UPN not an email address Error 2: Server Error in '/' Application. Runtime Error Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
  14. I'm generalizing of course about the kinds of accounts this could be done on, but I was thinking it could apply to just about any account type where there's already a password reset script. The problem I was specifically trying to solve for was for some Oracle DB accounts and was provided a script block to try to test by modifying a reset script. I would say that a bulk of the work is already done in the sense the reset scripts are already talking to the system/DBs. The scripts would just need to issue the "lock" command vs. the reset command. As for the specific execution, I was thinking it could be from the "Actions" dropdown menu or adding button next to the password field in the Edit password panel for a record as is done for the generation, toggle vis etc. choices (This may be safer as it requires more explicit actions to get there). It could reference the appropriate lock script and privileged account referenced in a tab like is done with an account with resets enabled does. Hope that helps clarify, and thanks for the consideration.
  15. I realize this probably gets into account management territory, so bear with me, but I think there's a relatively easy to implement feature. I would like to have an action on a record to be able to lock an account. The password reset/validation scripts already provide most of the base functionality to do to this for the various supported types of systems/dbs. This function would use the privileged account already assigned to the record for the reset script and bypass any heartbeat checking. This would allow a non-privileged user the ability to quickly lock an account without needing elevated rights on a system/db (directly). Since all the other RBAC stuff would already be in place on the record, there's not change in the security model (if a user had modify rights to change an reset a password, they would have rights to lock that account). So maybe a checkbox for "Enable Account Lockout" with a new tab to select an appropriate lockout script on the record details page. My specific scenario involves an Ops center needing to disable accounts on terminations, role changes etc. There are a large number of DBs with named users that need to have to access prevented (Need to be able to show a locked status for auditing since accounts are not immediately removed. A password change isn't sufficient.) when those events occur, requiring direct DB access to perform. We'll have a form of discovery that updates accounts in a specific "lockout only" password list in which we can ignore the account's actual password value (it's not needed due to using the privileged account to perform resets or hopefully, locks). Happy to expand on that further if it helps convey the idea. Thanks
×