I succesfully added a YubiKey to Snowflake MFA:
Next time I try to login I immediately get following "User is not enrolled in Duo Security. Contact your local system administrator." error:
After inputting my username and password, I expect the site to ask me to touch my YubiKey. Instead I immediately get the error described above.
How can I setup Snowflake MFA using a YubiKey security key?
Our local admin disabled my MFA and I repeated the steps and I got the same result.
Unfortunately this is not available on Snowflake side as of now.
I do agree there is a bit of confusion the fact that you are allowed to enroll with Yubikey but then fail to authenticate.
We do have an internal improvement request pending for this feature. I don't know a timeline yet but you can reach out to your Snowflake representative if you need more information.
Functionality might not be available with Snowflake, you can always enable Single Sign-on with your Identity provider and enable the yubi on the IDP end.
Snowflake has removed that "Security Key" option for all regions to avoid this problem. That option for Snowflake MFA is not supported at the moment
Related
I'm creating a set of hands-on lab users in my Azure AD for access to Azure Labs. We will reuse these user accounts (and reset the passwords after every lab session).
My challenge is that these users are being required to configure MFA. Which I THINK is called the Azure AD Interrupt Mode described here.
Is there a way to exclude these group of users from being required to set this up?
I think this can be disabled entirely by navigating to Azure AD - Default Directory - Properties - Manage Security Defaults (right at the bottom of the page) - Enable Security Defaults - set it to No.
If it's per user basis, then Navigate to Azure AD - All users - Per User MFA - this will list all the users and then you can select "n" number of them to either enable or disable MFA.
// Answering my own question and hope it helps someone.
The first and obvious step is to disable MFA. This is described in this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
After this, however, you may still face the interrupt wizard as shared in the screenshot of the question above. This is due to Self-Service Password Reset (SSPR) being enabled. If SSPR is enabled, then MFA is still required for them to be able to do a password reset.
Solution 1: If you want SSPR enabled, then create a Conditional Access policy requiring MFA upon sign in.
This way, MFA is only triggered when user wants to do an SSPR.
For this lab user scenario, you will still have to set-up MFA one-time for each of the users (you may use the same contact details).
Extra note: I tried setting the MFA details by bulk using PowerShell. However, it is not possible to set an MSOL user object's StrongAuthenticationUserDetails property.
Solution 2: Disable SSPR or limit to selected users using AD groups
Don't include the lab users in the selected users group. Since SSPR is not allowed for these users, the extra MFA details won't be asked of these users anymore.
Drawback: The setting is to include user groups which should have SSPR. There's no option to exclude just the lab users.
Solution 2 works for me but may not work for everyone.
I'm trying to login into my staging Salesforce lightning, by I get the following result:
INVALID_LOGIN: Invalid username, password, security token; or user locked out.
I use the 'jsForce' library version 2, with the right serverUrl, username and password+token combination.
Note that when I do exactly the same for my production Salesforce environment - I succeed.
Any suggestion to why there's a difference between staging and production - would be helpful.
"exactly the same" to prod is probably bad idea, https://test.salesforce.com vs https://login.salesforce.com ;) And even if you have same password - the token could be different, password could have expired.
Do you see anything in the user's login history in setup? It's hard to guess these things. Do you get same result if you try SOAP API login or OAuth2? Or even plain old SF Data Loader?
Maybe admin went to Setup -> My Domain and disabled logging in from generic address, forcing you to go https://mydomain--mysandboxname.my.salesforce.com/... ?
Maybe admin enforced Single Sign-On on everybody and you can't use SF username & pass anymore.
There might be restricted IP addresses or login hours set
Found a Solution: when logging to Salesforce using the jsForce libray, only the 'loginUrl' parameter works as expected (as opposed to 'serverUrl' for production).
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
I'm trying to work out why some of our users aren't issued claims by our custom attribute stores.
Our main attribute store for authentication is Active Directory, but we are using two custom attribute stores to issue several custom claims to users, and also to perform some logging of claims issued. When an affected user logs in, they are authenticated successfully by AD, but have no more claims added. According to the logging in our attribute stores, the BeginExecuteQuery is never called.
I can't see anything to link the affected users, but they mainly seem to be new users, or users that have not logged into the system in a long time. Restarting ADFS sometimes clears the problem, but whether it does or not seems to be random.
I'm trying to understand why an attribute store would be ignored by ADFS on logon for certain users, when it works fine for others. If there is a quick guaranteed temporary fix to get users' claims issued correctly, that would be useful too!
For security reasons, I don't have access to the ADFS Debug tracing.
This was eventually solved with a longs string of calls to Microsoft's AD FS support team. The problem was traced to a piece of our claims rule language which was using the lastLogon and lastLogonTimestamp AD attributes without understanding how they actually behaved. This meant that for some users the condition to grant the custom claims was never met.
If a user logs in to their computer using a Single Sign-On system such as Active Directory, LDAP, or Kerberos, is it possible for applications they run to know who they are and what system they authenticated with? Can I get enough information out of these systems to verify their identity without requiring any additional user input?
Specifically, I would like to be able to check these things:
Did they log in via a single sign-on system at all, or are they just using a regular user account on this machine?
What system did they use?
Does the system have some URI that would distinguish it from any other directory?
What is the current user's distinguished name in that directory?
Can I get some information which I can pass to another host to prove to that host that the user is who they said they are? For example, a token that can be used to query the SSO system.
I'd assume all of these things should be possible, and in fact encouraged, but I am not positive. I'm sure the method of getting at this information is
SSO (at least with Kerberos which is used by ActiveDirectoy) is based on a token. As soon as the user requests access to a kerberized system the system queries for the token and checks its validity for accessing the system. It's as good as querying for username and password. when the user did not log in with an Kerberos-account there is no tiket so no automated access.
using the token you can get the users login- name and from that you can then use that to query the SSO-backend (typically LDAP) for more information on that user.
LDAP is not an SSO-system as it is simply a storage query protocol but it is often used as backend for SSO-systems.
The problem often is kerberizing an application. for Webapps that means you have to kerberize the webserver so that that one then can handle the authentication process with the SSO-service and then pass that information on to the unferlying webapp.
Hope that answers you questions.
for more information have a look around the web for kerberos
You are really asking about two things:
Authentication: Who are you?
Authorization: What are you allowed to do?
Kerberos really only answers the first question, you need a secondary system like LDAP or Active Directory ( which is both kerberos and ldap in a single server) to answer the second.
If your system is using kerberos correctly, any user login should have an associated kerberos ticket. With this ticket, you can request "service" tickets
to prove your identity to remote servers that support kerberos. The ticket
contains your principal identity in the realm ( user#DOMAIN.NET ) that can be
used to query authorization systems.
However, the details required to get all the moving parts in that sentence working together "on the same page" so to speak can be very complex. The remote service has to support accepting kerberos credentials, it has to be either in the same realm or have a cross realm trust relationship configured.... The list
gets pretty long. Depending on your exact application environment, using all these things can be fairly trivial, or it can be next to impossible.