Using Oracle Wallet authentication for Oracle Discovery on Windows - Support and Troubleshooting

Using Oracle Wallet authentication for Oracle Discovery on Windows .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Oracle Wallet Authentication for Discovery (Windows) 1. Overview Discovery can authenticate to an Oracle Database using an Oracle Wallet configured on the target Windows host, instead of using a username and password stored in ServiceNow. This lets customers who already use Oracle Wallet across their estate keep credentials out of ServiceNow while still discovering Oracle instances and related components. On Windows there is an additional benefit. Previously, remote SQL queries were executed by invoking SQL*Plus with the credentials on the command line (sqlplus user/password@sid). On Windows this exposed the database user and password in clear text in the host's runtime process listing during query execution. When wallet authentication is enabled, SQL*Plus is invoked with the /nolog flag and connects through the wallet, so no credentials ever appear on the command line or in the Windows process list.

The feature is off by default and must be enabled explicitly.

2. How Discovery authenticates when the feature is enabled When Oracle Wallet authentication is enabled, the supported Discovery patterns:

Locate the Oracle installation on the target host. Use the Oracle Wallet already configured on that host — located through the TNS_ADMIN directory and sqlnet.ora — to connect to the database. Run the SQL queries needed to collect Oracle Instance details and related component data, invoking SQL*Plus with the /nolog flag and connecting with connect /@ , so that no credentials appear on the command line or in the Windows process list. Send no Oracle username or password from ServiceNow during these queries. 3. Enabling the feature Setting Value System property glide.discovery.oracle_wallet_authentication Type True / False Default false (disabled) Effect when true The Discovery patterns listed in section 5 will use Oracle Wallet authentication on Windows targets. In the patterns this property is evaluated as the enable_oracle_wallet_authentication attribute, which activates the wallet-authentication (failover) steps. To enable , set the property to true in your ServiceNow instance. To turn it off again, set it back to false .

Note: Until the property is set to true , Discovery continues to use standard username/password credentials and behavior is unchanged.

4. Prerequisites on the target host The following must be true on each Oracle Windows host before Discovery can authenticate with the wallet. The customer is responsible for confirming each item on the host; ServiceNow Support cannot troubleshoot wallet-side issues that have not first been validated locally on the target.

The Discovery user can reach and authenticate to the Windows host. This is the same requirement as any other Windows Discovery (the MID Server connects using the configured Windows credential). An Oracle Wallet (auto-login wallet) is configured and working on the host for the intended OS user. Logged in locally as that user, the customer must be able to connect to the database with no password prompt, using the example from the Oracle documentation: connect /@ Or, equivalently: sqlplus -s /nolog connect /@

Per Oracle's documentation, each user account must have its own unique connect descriptor The (TNS alias) used here must be the one defined in tnsnames.ora and configured in the wallet for the target instance. The wallet and TNS configuration are readable by the account Discovery runs as. On Windows there is no sudo; the SQL*Plus process runs under the MID Server's Windows service account. That account must have NTFS read and execute permissions on both the wallet directory (cwallet.sso, ewallet.p12) and the TNS_ADMIN directory (sqlnet.ora, tnsnames.ora) . A typical grant that meets this requirement: icacls "C:\Oracle\network\admin\wallet" /grant "DOMAIN\MIDServiceAccount:(R)(RX)" /T Replace the path with your wallet location, and DOMAIN\MIDServiceAccount with the Windows service account the MID Server runs as. This NTFS permission grant is the Windows equivalent of the passwordless sudo requirement used on Unix/Linux — it is what allows the discovery process to open the wallet. sqlnet.ora points to the wallet and enables auto-login, and tnsnames.ora contains the connect descriptor for the target instance. WALLET_LOCATION must reference the wallet directory, and the auto-login (SSO) wallet must be in place so that connect /@ succeeds without a password. If any of these conditions is not met, Discovery will not be able to authenticate using the wallet on that host.

Before opening a ServiceNow support case: On the target host, logged in (or running) as the Windows account the MID Server uses to execute commands, run sqlplus /@ . If that command does not connect without a password — for example it fails with a permission error or a wallet error — the issue is with the Oracle Wallet configuration or the NTFS permissions on the host and must be resolved with your Oracle DBA / Windows administrator before ServiceNow Support can assist. This KB is not a substitute for a working Oracle Wallet configuration. 5. Supported Discovery patterns (Windows) Oracle Wallet authentication is supported by the following Discovery patterns:

Oracle DB on Windows Oracle Windows for SAM customers Oracle Enrich Attributes Extend Oracle Instance Get Catalogs info Get Oracle Instance size info Get Oracle Health Report Oracle GLAS Data Collection V1 Oracle GLAS Data Collection V2 Patterns not listed above continue to use standard credential-based authentication.

6. What changes for the customer Credentials in ServiceNow: You no longer need to store Oracle database credentials in ServiceNow for the supported patterns, provided every target host has a working Oracle Wallet for the intended OS user. What is discovered: The data collected by the supported patterns is the same as before. Only the way Discovery authenticates changes. Reverting: Setting glide.discovery.oracle_wallet_authentication back to false returns Discovery to standard credential-based authentication immediately on the next run. Summary Oracle Wallet authentication for Discovery removes Oracle DB credentials from ServiceNow for the supported Windows patterns, and removes them from the Windows host's process listing during query execution. It does not change what is discovered, only how Discovery authenticates. The wallet itself is owned and maintained by the customer on the target host: Discovery will only succeed where the MID Server can reach the host, a working wallet exists for the intended account (verifiable with sqlplus /@ ), and the MID Server's Windows service account has NTFS read/execute permissions on the wallet and TNS_ADMIN directories. Validate those items on the host before opening a ServiceNow support case.

References Oracle — About credential wallets: https://docs.oracle.com/en/database/oracle/machine-learning/oml4py/2/mlpug/oracle-wallets.html Oracle — Managing the Secure External Password Store for Password Credentials: https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-authentication.html#GUID-803496D2-19C7-4F02-94EC-C13EDD8FB17B