PIV authentication: Access and Oracle (4 Viewers)

[mempie]

Hello everyone. This question will start out a bit vague, and become clearer as I understand better what we are doing. Please bear with me.

I maintain a database with an Access interface connected to an Oracle 19c database via ODBC. Users log in using their Oracle credentials. Our government client is imposing a mandate to authenticate all our databases using our PIV. We are not an Access shop. Mine is the only database with an Access interface, and I'm the only Access programmer here. I have never used the other databases. I think people use CyberArk and their PIV PIN to connect to jump servers and utility servers, from where they connect to their databases possibly using SQL Plus. I have heard about another team developing web-based interfaces and dashboards using things like Power BI, but I don't know the details. They have talked about replacing my Access interface with such tools for years, but I don't see it happening.

I'm not the DBA. Our Oracle DBAs are not programmers, Access experts, ODBC experts, or Windows experts. So far, I have been told that I can use CyberArk for this task, or some other method. Tomorrow there's a meeting where (I think) the requirements will be laid out more clearly. As it is, we use our PIV credentials to log onto Windows, and again for CyberArk and once again separately for some government intranet sites, such as our trouble ticket system.

My initial web searches indicate that there aren't any existing tools to connect Access to CyberArk. Oracle can be set up with an "Oracle Wallet" to use PIV credentials instead of a username and strong password. ODBC can supposedly work with that system. The DBA isn't familiar with that setup, it seems.

My questions now are: 1) what are good questions to ask during tomorrow's meeting, and 2) broadly speaking, what are right and wrong ways to make this happen?

Thank you. I'll let you all know how the meeting goes.

 

[NauticalGent]

I have no idea on how to answer your question, so I consulted the tool most Devs hate, ChatGPT, in this case Code Copilot:

This is actually a very real problem in government environments, and the poster is not crazy — the intersection of Access + Oracle + PIV + CyberArk + ODBC is a perfect storm of technologies that were never designed to work together cleanly.
Given your background with Access front-ends, SQL backends, government environments, and security mandates, this situation is right in your wheelhouse.
Let’s break it down so you can see what’s really going on and what smart questions they should ask in the meeting.

---

First: What the mandate probably means​

When government IT says:

“All databases must authenticate using PIV”

they usually mean:

• CAC/PIV smart-card authentication
• Certificate-based authentication
• Often enforced through PKI infrastructure
• Sometimes combined with CyberArk credential vaulting

The intent is usually:

Old Model	New Model
Username + password	Smart card certificate
Password stored in app	External authentication
App controls login	Enterprise identity controls login

The Access app becomes a problem because:
Access normally authenticates via:

ODBC DSN
   -> username/password
   -> database

But PIV authentication is not username/password based.

---

The key technologies mentioned​

The poster mentioned several things — each has different implications.

CyberArk​

CyberArk is not authentication.
It is a privileged credential vault.
Typical use:

User -> CyberArk -> retrieves DB password -> connects to DB

CyberArk is mainly used for:

• service accounts
• shared accounts
• admin credentials

CyberArk does NOT normally integrate with Access ODBC connections.
So if someone said:

“Use CyberArk”

that probably means they don't understand the problem.

---

Oracle Wallet​

This is much more relevant.
Oracle Wallet allows certificate-based authentication.
Meaning:

Smart card certificate
   -> Oracle Wallet
      -> Oracle DB authentication

Instead of:

username/password

Access could connect via ODBC using:

External authentication

But this requires proper Oracle client configuration.

---

PIV Authentication​

A PIV card contains certificates.
These certificates can be used for:

• Windows login
• VPN
• Web authentication
• Database authentication (if configured)

But the database must support certificate mapping.
Oracle can do this.

---

ODBC​

ODBC itself does not care about PIV.
It just passes credentials.
The trick is configuring the Oracle driver to use:

/ (external authentication)

instead of:

username/password

---

What the correct architecture should look like​

The clean architecture is:

User logs into Windows with PIV
      ↓
Windows has certificate
      ↓
Oracle client uses certificate
      ↓
ODBC connection uses external authentication
      ↓
Access connects without storing password

Example ODBC connection:

UID=/

The slash means:

Use OS authentication

This is supported by Oracle.

---

What they should ask in the meeting​

These are excellent questions the developer should bring.

---

Is the requirement PIV or PKI authentication?​

Very important.
Ask:

“Is the requirement PIV authentication specifically, or PKI certificate authentication?”

Because:

PIV = smart card
PKI = certificate

Most systems actually require PKI, not the card itself.

---

Does Oracle already support external authentication?​

Ask:

“Is Oracle configured for External Authentication (OS or PKI)?”

Oracle supports:

OS authentication
Kerberos
PKI
password

If external auth isn't configured, the DBAs must enable it.

---

Is Oracle Wallet available?​

Ask:

“Is Oracle Wallet configured for client authentication?”

This is often the correct solution.

---

Is the Oracle client installed locally?​

Access connects through the Oracle ODBC driver.
So the workstation must have:

Oracle Client
Oracle ODBC driver
Oracle Wallet configuration

---

Will DSN or DSN-less connections be required?​

Important for Access apps.
Ask:

“Will workstations be configured with Oracle Wallet and DSNs, or must the application handle authentication?”

---

Is CyberArk actually required?​

Ask directly:

“Is CyberArk part of the authentication flow, or only used for privileged accounts?”

Because CyberArk is usually irrelevant here.

---

Wrong approaches (very common in government)​

These are mistakes teams frequently make.

Storing PIV PIN in the application​

Impossible and illegal.

Passing PIV credentials through ODBC​

Not supported.

Using CyberArk for user authentication​

CyberArk is not meant for that.

Requiring Access to prompt for certificate​

ODBC usually can't do that directly.

---

Right approaches​

These are realistic solutions.

---

Oracle External Authentication​

Best option.
User logs into Windows using PIV → Access connects without password.

---

Oracle Wallet​

Second best option.
Wallet stores certificate mapping.
Works well with ODBC.

---

Kerberos (sometimes used)​

If the environment already uses Kerberos.

---

Application server middle tier​

This is what the Power BI/web team probably wants.
Architecture becomes:

Access → API → Oracle

But that requires a full rewrite.

---

My prediction of what will happen​

Based on your experience with government IT (and mine), the meeting will probably go like this:
Security says:

“Everything must use PIV.”

DBAs say:

“We don't know how.”

Someone says:

“Maybe CyberArk?”

Everyone looks at the Access developer.
Nothing gets decided.
Months pass.
They finally configure Oracle Wallet.

---

What the Access developer should push for​

The best answer they can advocate for is:

Use Oracle External Authentication via PIV certificates and Oracle Wallet, configured in the Oracle client used by the ODBC driver.

This keeps the Access app unchanged.

---

What I would ask immediately​

If I were in that meeting, my first question would be:

“Is Oracle already configured for PKI authentication using Oracle Wallet?”

Because if the answer is no, then the Access developer cannot solve this problem — it must be solved by the Oracle DBAs and security team.

---

One thing you will appreciate​

Because you've been working on WMT with Access front-end architecture, you'll immediately see the real issue:
This isn't an Access problem.
It's a database authentication architecture problem.
Access is just the messenger.

---

If you'd like, I can also show you something really interesting:
Why Access + Oracle via ODBC is often dramatically faster than web dashboards like Power BI for operational systems, which is why those replacements often fail.
That topic gets spicy.

This may help, it may be BS - OR - maybe you have already went this route. At any rate, I didn't want your post to go unanswered.

 

[mempie]

I have no idea on how to answer your question, so I consulted the tool most Devs hate, ChatGPT, in this case Code Copilot:

This is actually a very real problem in government environments, and the poster is not crazy — the intersection of Access + Oracle + PIV + CyberArk + ODBC is a perfect storm of technologies that were never designed to work together cleanly.
Given your background with Access front-ends, SQL backends, government environments, and security mandates, this situation is right in your wheelhouse.
Let’s break it down so you can see what’s really going on and what smart questions they should ask in the meeting.

---

First: What the mandate probably means​

When government IT says:

they usually mean:

• CAC/PIV smart-card authentication
• Certificate-based authentication
• Often enforced through PKI infrastructure
• Sometimes combined with CyberArk credential vaulting

The intent is usually:

Old Model	New Model
Username + password	Smart card certificate
Password stored in app	External authentication
App controls login	Enterprise identity controls login

The Access app becomes a problem because:
Access normally authenticates via:

ODBC DSN
   -> username/password
   -> database

But PIV authentication is not username/password based.

---

The key technologies mentioned​

The poster mentioned several things — each has different implications.

CyberArk​

CyberArk is not authentication.
It is a privileged credential vault.
Typical use:

User -> CyberArk -> retrieves DB password -> connects to DB

CyberArk is mainly used for:

• service accounts
• shared accounts
• admin credentials

CyberArk does NOT normally integrate with Access ODBC connections.
So if someone said:

that probably means they don't understand the problem.

---

Oracle Wallet​

This is much more relevant.
Oracle Wallet allows certificate-based authentication.
Meaning:

Smart card certificate
   -> Oracle Wallet
      -> Oracle DB authentication

Instead of:

username/password

Access could connect via ODBC using:

External authentication

But this requires proper Oracle client configuration.

---

PIV Authentication​

A PIV card contains certificates.
These certificates can be used for:

• Windows login
• VPN
• Web authentication
• Database authentication (if configured)

But the database must support certificate mapping.
Oracle can do this.

---

ODBC​

ODBC itself does not care about PIV.
It just passes credentials.
The trick is configuring the Oracle driver to use:

/ (external authentication)

instead of:

username/password

---

What the correct architecture should look like​

The clean architecture is:

User logs into Windows with PIV
      ↓
Windows has certificate
      ↓
Oracle client uses certificate
      ↓
ODBC connection uses external authentication
      ↓
Access connects without storing password

Example ODBC connection:

UID=/

The slash means:

Use OS authentication

This is supported by Oracle.

---

What they should ask in the meeting​

These are excellent questions the developer should bring.

---

Is the requirement PIV or PKI authentication?​

Very important.
Ask:

Because:

PIV = smart card
PKI = certificate

Most systems actually require PKI, not the card itself.

---

Does Oracle already support external authentication?​

Ask:

Oracle supports:

OS authentication
Kerberos
PKI
password

If external auth isn't configured, the DBAs must enable it.

---

Is Oracle Wallet available?​

Ask:

This is often the correct solution.

---

Is the Oracle client installed locally?​

Access connects through the Oracle ODBC driver.
So the workstation must have:

Oracle Client
Oracle ODBC driver
Oracle Wallet configuration

---

Will DSN or DSN-less connections be required?​

Important for Access apps.
Ask:

---

Is CyberArk actually required?​

Ask directly:

Because CyberArk is usually irrelevant here.

---

Wrong approaches (very common in government)​

These are mistakes teams frequently make.

Storing PIV PIN in the application​

Impossible and illegal.

Passing PIV credentials through ODBC​

Not supported.

Using CyberArk for user authentication​

CyberArk is not meant for that.

Requiring Access to prompt for certificate​

ODBC usually can't do that directly.

---

Right approaches​

These are realistic solutions.

---

Oracle External Authentication​

Best option.
User logs into Windows using PIV → Access connects without password.

---

Oracle Wallet​

Second best option.
Wallet stores certificate mapping.
Works well with ODBC.

---

Kerberos (sometimes used)​

If the environment already uses Kerberos.

---

Application server middle tier​

This is what the Power BI/web team probably wants.
Architecture becomes:

Access → API → Oracle

But that requires a full rewrite.

---

My prediction of what will happen​

Based on your experience with government IT (and mine), the meeting will probably go like this:
Security says:

DBAs say:

Someone says:

Everyone looks at the Access developer.
Nothing gets decided.
Months pass.
They finally configure Oracle Wallet.

---

What the Access developer should push for​

The best answer they can advocate for is:

This keeps the Access app unchanged.

---

What I would ask immediately​

If I were in that meeting, my first question would be:

Because if the answer is no, then the Access developer cannot solve this problem — it must be solved by the Oracle DBAs and security team.

---

One thing you will appreciate​

Because you've been working on WMT with Access front-end architecture, you'll immediately see the real issue:
This isn't an Access problem.
It's a database authentication architecture problem.
Access is just the messenger.

---

If you'd like, I can also show you something really interesting:
Why Access + Oracle via ODBC is often dramatically faster than web dashboards like Power BI for operational systems, which is why those replacements often fail.
That topic gets spicy.

This may help, it may be BS - OR - maybe you have already went this route. At any rate, I didn't want your post to go unanswered.

Thank you. This is the kind of answer I was seeking. Here are more details about our environment:
1. Users of my database have Oracle Client 19c installed on their laptops (for 32 or 64-bit, depending on the age of the machine). I suppose the users all have SQL Plus and could, if they knew how, connect to our database directly that way and do stuff.
2. Our Oracle database lives on AWS using RDS. It used to live on one of our Linux servers, and was developed there, moving to AWS a couple of years ago.
3. Your "best option" Oracle External Authentication presumably doesn't conform to the requirement being imposed, as I think you noted.
4. I asked the DBA some questions about our Oracle setup. He responded by saying that he wasn't invited to tomorrow's meeting. Maybe the meeting isn't about PIV authentication. It was called by a project manager I don't know, and is about "cloud governance" and "tenant review".

What is WMT?

 

[NauticalGent]

WMT is MY application. I have asked a few questions and it retailns that info

 

[The_Doc_Man]

I looked over NG's post very carefully since I was in a relatively similar environment and held a couple of security-related and O/S related certificates with the U.S. Navy office where I worked.

I believe that you should listen carefully during that meeting and retain the idea that this isn't an Access problem, it is a database authentication problem for which Access is simply a middle-man. Not that you would ever actually do this, but it is no different than using Notepad or Wordpad to open your ORACLE .DBF content. The utility isn't the issue, it's the data. You can point out that if someone opened Access but didn't have proper credentials for the back-end, the BE should be the stopper.

For technical reasons related to Windows File Locking, the Access FE should always be a private copy of the app file and the BE that contains critical data is the place that must be carefully protected. But other than "trusted folder" issues for the FE file, it will be private in the sense that nobody else would ever use YOUR copy. They would have a copy of their own.

Beware of cloud issues. Access doesn't always play well with clouds, since you brought that up in #4 bullet of your previous list. HOWEVER, you suggested that Access won't be handling the cloud, you will be doing ODBC connections, which are different than native Access BE files anyway. In that case, being in a cloud is less of an issue.