Jump to content

cwaters

Members
  • Content Count

    10
  • 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. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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
×