Introduction
Dating back to the start of 2025, Snowflake has been discussing major upcoming changes to their authentication systems. Having joined the Multi-Factor Authentication (MFA) train, they can now claim stronger defenses for their constituents against potential breaches. MFA accomplishes this by requiring a second degree of proof of identity upon login. For users of the web UI Snowsight, this is easy – put in your user ID, await the push notification on your phone from Duo (the default provider), and confirm there that the login is authentic.
Unsurprisingly, the default push notification method for MFA has its detractions, and no shortage of dissenters. Though it is factually more secure than the incumbent method of user/password (plus the network policy of CIDR-block allow/block lists), some users prefer not to engage with a cell phone in order to do their jobs; others using third party software, like SAS, don't enjoy the repetitive pinging when accessing Snowflake endpoints; and others still find it completely incompatible with scheduled jobs. After all, nobody wants to wake up at 3AM just to approve their service user’s daily workload… right?
SAS 9 is no exception to these blockers – many SAS 9 & EG users alike are looking to SAS for guidance on how to navigate the upcoming MFA mandates without interrupting their pipelines before the mandates go into effect. This post will address exactly that using key-pair authentication, one of three main methodologies recommended by Snowflake. Before we get started, let’s iron out which personas you need to future-proof your SAS & Snowflake pipelines:
An admin user for the Snowflake account – preferably someone with access to the ACCOUNTADMIN role.
An admin user for the SAS 9 license.
For server-side SAS 9 environments, the admin must have access to central machine on which SAS 9 is running.
For client-side SAS 9 environments, users will individually configure their machines – but some team administrator will still be required to generate key pairs.
Now, let’s dig in step by step on how to implement the key-pair methodology. Please note that this is supported for Maintenance versions 9.4M6 and later.
Section 1: Ensuring Permitted SAS/Snowflake Traffic
The first thing a Snowflake admin needs to do is configure (or confirm) networking rules for the Snowflake account that will accept incoming requests from SAS 9. For server-side SAS 9 environments, the only IP Address needed is the server. For client-side SAS 9 environments, however, the IP Addresses of all users’ machines are necessary – this can be quite a hassle, which is where the common corporate VPN comes in handy. In this case, all that’s necessary is the CIDR block occupied by the corporate VPN. As long as SAS users are connected to the VPN, Snowflake won’t block their client requests. Once the full list of allowed IP’s or CIDR blocks is prepared, a Snowflake admin can alter the account’s network policy as follows:
In this code block, we assume the proper role and obtain the name of the active NETWORK POLICY. We then create a NETWORK RULE (this can always be altered later if the allowlist must change) that can the Snowflake environment to accept traffic requests from users leveraging the SAS 9 environment. Lastly, we add the rule to the policy, enacting this conditional access to the environment.
Section 2. Setting up Key-Pair Authentication in the Snowflake Account
Before demonstrating the process for giving an individual user the possibility to authenticate using a key-pair, a note: if your SAS environment contains a large user base (i.e. hundreds of users), the manual provisioning of key-pair authentication can be tedious, even grueling. It is strongly recommended to investigate the usage of scripting and user-defined functions to automatically generate the key-pairs and assign them to Snowflake users, respectively. With that noted, let’s discuss how to implement each user’s key-pair authentication. For optimal practices, the execution of Snowflake statements in this section should be conducted by an administrator leveraging the SECURITYADMIN role (or higher).
To generate the key-pair, follow along with Snowflake’s official documentation. It is recommended to use an encrypted key. Do not deviate from Snowflake’s key-generation procedure, as differently formatted keys will fail.
Keep track of the location of both the private key file (.p8) and the private key file’s password. It may be useful to create a user directory structure to track which files and password are associated with each user. It may also be useful for users to store their passwords in a key vault (on top of ideally remembering it).
Use the ALTER USER statement to add the RSA_PUBLIC_KEY parameter. If the user does not yet exist in the Snowflake environment, you can create them as follows:
In current (as of this article, dated August 2025) Snowflake bundles, MFA has not yet been made 100% mandatory. As such, there are still opt-in’s and opt-out’s. To ensure that the key-pair methodology is working, enable MFA for the user. For now, whenever the user authenticates without the key, they will have to address push notifications to satisfy MFA:
With the Snowflake-side management handled – if using client-side SAS 9 on Windows, go to the SAS 9 Client-Side Windows ODBC Set-Up section. If using a server-side SAS 9 environment (regardless of the client OS), go to the SAS 9 Server ODBC Set-Up Section. For client-side Mac and Linux SAS 9 environments, the procedure will align very closely with the Server ODBC Set-Up, the main difference being the file references are on the client machine, not a centralized server.
Section 3a: SAS 9 Client-Side Windows ODBC Set-Up
For many SAS 9 users, there is no central server to which all users connect. Sometimes, users, especially in test & dev environments, design their workloads and run their compute from their home machine. This section addresses how those users can individually configure their Snowflake connections to satisfy the MFA mandate:
If not already done, follow the Snowflake documentation to install the ODBC driver on the machine. Make sure not to skip the section on the “Visual C++ Redistributable for Visual Studio 2015.”
With the driver installed, open the “ODBC Data Sources (64-bit)” program on the machine.
Click “Add” to create a new Data Source Name (User DSN and System DSN both work here – but note which one!), select the “SnowflakeDSIIDriver” option, click “Finish,” and populate it. Note that the database, schema, warehouse, and role can all be overwritten by a LIBNAME statement, so long as the Snowflake user has access to the requested resources. Also note the inclusion of the snowflake_jwt value in the Authenticator field. The authenticator tells the system not to use a username & password combination to login to Snowflake, instead using the private key file & password:
Clicking the “Test” button at this point will fail, because while the ODBC system knows not to leverage a user & password to authenticate, it does NOT yet know where the key file & password that it must use are. In order to instruct the system to leverage this information, they must be defined with respect to the DSN. With the newest versions of the ODBC program & Snowflake Driver, this can actually be done in the above GUI by entering the private key file location and password in their respective cells. In this case, enter both the file path and the password without quotes, then skip to step 9. In older versions, like the one in the above screenshot, we must instead use the "Registry Editor". Click “OK” and open the Registry Editor (regedit) program on the machine:
Registry Editor is useful for entering options for ODBC DSN’s that aren’t visually present in the Windows GUI. The two options necessary for this implementation are PRIV_KEY_FILE and PRIV_KEY_FILE_PWD, neither of which are present in the GUI from Step 3.
If Step 3 created a USER DSN: follow the path “Computer\HKEY_CURRENT_USER\Software\ODBC\ODBC.ini.”
If Step 3 created a SYSTEM DSN: follow the path “Computer\HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.ini.”
Locate the entry under ODBC.ini corresponding to the newly created DSN:
Right click anywhere in the right-side of the screen (which contains all the keys & values associated with the DSN) and select “New -> String Value.” Enter the name PRIV_KEY_FILE. Repeat this with a value of PRIV_KEY_FILE_PWD.
At this point, there are two unpopulated options defined for the DSN. To define each one, simply double-click it and paste in the value.
For the PRIV_KEY_FILE option, copy the file path of the private key (.p8) file located on the machine. Do NOT surround the file path with quotes.
For the PRIV_KEY_FILE_PWD option, copy the password defined for the encryption when the key was generated.
Close the window.
With the options added to the DSN and defined, the DSN can be tested. Reopen the GUI in Step 3 by double-clicking its corresponding entry in the ODBC menu, then select “Test.” If successful, there will be a confirmation dialog, and there will be no push notifications sent to the MFA-enrolled user. Additional confirmation of success can be done by editing the ODBC DSN definition, removing the snowflake_jwt value from the authenticator option, and re-running the “Test” button. In this case, the user should immediately be sent a push notification asking for identity verification, confirming the authenticator is doing its job. Re-enter the snowflake_jwt value and close the ODBC Data Sources window.
Section 3b: SAS 9 Server ODBC Set-Up
Unlike single-user environments, many deployments of SAS 9 are centralized on a Linux server. For the individual user, the access to SAS may still be via the SAS 9 client program, or Enterprise Guide, but the compute and external connections for all users are centralized on some remote machine. This section addresses how a SAS administrator can configure multiple users’ key-pair connections from the SAS Server to Snowflake.
If not already installed on the Linux machine, follow the Snowflake documentation to install the ODBC Driver.
Locate the following server-side files: ODBC.ini, ODBCINST.ini, and simba.snowflake.ini as listed in the Snowflake documentation.
If the Snowflake driver has not been configured at all, continue following the directions to configure the simba.snowflake.ini and ODBCINST.ini files.
In the ODBC.ini file, create a line for the DSN connection to the Snowflake account:
Then, add an entry for the DSN’s options, and add the following information:
Do NOT include the PRIV_KEY_FILE or PRIV_KEY_FILE_PWD in the DSN definition UNLESS the environment intentionally uses the SAME key-pair for ALL Snowflake users. Sharing key-pairs across multiple users is heavily discouraged. As such, in most, if not all, production environments, every user will have a unique key-pair, which will be referenced in the LIBNAME statements that leverage this DSN.
For SAS 9 environments with a significant number of users, the process of creating unique key-pairs for every user and implementing them in a POSIX-controlled structure on the SAS 9 server can be tedious. A shell script to loop through the user base and manage the permissions on the private key files can relieve much of this difficulty.
Section 4: Connecting from SAS to the Snowflake Account
Now that the Snowflake account has been successfully configured, the final step is to test the connection from SAS itself. Just as with any other SAS library, the connection to Snowflake is created with a LIBNAME statement.
For client-side SAS 9 installations, the LIBNAME statement can directly reference the DSN, only overwriting the connection parameters that may change from a day-to-day basis at the user’s discretion, like database, schema, or role:
Based on the options entered when the DSN was configured on the local machine, any unlisted connection options will be automatically populated from the DSN itself. Thus, there’s no need to reference the options like PRIV_KEY_FILE, PRIV_KEY_FILE_PWD, or authenticator in the LIBNAME statement. Users are, as always, free to add other LIBNAME options to their statements.
For a server-side SAS 9 installation, the LIBNAME statement requires a little more individual configuration and change from its pre-MFA code. With a server-side installation, the LIBNAME statement references the DSN defined by the administrator in the ODBC.ini file on the Linux server. In the standard setup wherein multiple users connect to the same SAS 9 server, said users will have different private key files & passwords, as discussed in Section 3b. As such, the DSN itself could not define a single blanket value for PRIV_KEY_FILE or PRIV_KEY_FILE_PWD to propagate to all users. Instead, each user must define those two connection options in their LIBNAME statement, pointing to their respective key and password:
This methodology allows multiple users to leverage the same Snowflake DSN (in turn, leveraging the Snowflake Driver configured on the machine) but with unique key-pairs, thus satisfying both MFA requirements and organizational security mandates.
Parting Words
I hope this article provides clarity for users and administrators alike in joint deployments of SAS 9 & Snowflake. The key-pair authentication methodology provides a safe and secure pathway to satisfying Snowflake’s MFA requirements without potentially sacrificing workload efficiency by using push notifications. This can play a large role in reducing blockers, especially for teams with significant scheduled or service workloads.
In future updates I will explore the step-by-step differences in setup for this methodology for users of SAS Viya, in addition to discussing the wider breadth of supported authentication options that Viya brings. Feel free to send any questions or comments to me at Joe.Cabral@sas.com. As always, thanks for reading, and for playing my new favorite writer’s game: “is this hyperlink for documentation or a 90’s music video?”
... View more
