Oracle named user plus audit issues.

Named user plus is Oracle's per user licence metric for the Database product line and for many other Oracle products. The metric counts every human and every device that connects to the licensed product, subject to a minimum count per processor as defined in the licence definitions document. Named user plus sounds simple. In practice, the metric drives more audit findings than any other Database licensing dimension, because the definition is broader than customers expect, the minimum requirement is often ignored, and the audit script captures connections customers did not know about.

This article walks through the named user plus issues that recur in Oracle Database audits. It covers the definition, the minimum requirement, the multiplexing question, and the buyer side framework for getting the count right.

The named user plus definition

Oracle's licence definitions document defines a named user plus as a person or non human operated device that is authorised to use the programs which are installed on a single server or multiple servers. The definition has three components. First, the count includes both human users and non human devices. Second, the count covers authorisation, not active use. A user who is authorised but does not currently log in still counts. Third, the count covers the programs installed on the licensed servers, regardless of which server the user actually connects to.

The implication is that the named user plus count covers far more than the active users of the application that sits on top of the database. It covers every user of every application that touches the database, every batch process account, every monitoring tool account, every replication endpoint, and every device that connects through automated processes. Customers commonly count only the application end users and arrive at a number that is a small fraction of the actual licensable count.

The minimum requirement per processor

Oracle Database Enterprise Edition carries a minimum named user plus requirement of 25 users per processor. Standard Edition carries a minimum of 10 users per processor. The minimum applies even when the actual user population is smaller. A customer running Enterprise Edition on a four processor server has a minimum licensable count of 100 users, regardless of whether the actual user population is 10 or 1,000.

The minimum is the source of significant audit findings on customers who have correctly counted users but have not applied the minimum. A small finance team running a four core Enterprise Edition database may have 12 actual users. The licensable count is 100. The shortfall is 88 user licences at list price, plus back support. The buyer side response is to model the minimum at every Enterprise Edition deployment and choose the metric, named user plus or processor, that produces the lower licence count at the deployment. What LMS looks for covers the metric selection mechanics.

The multiplexing question

Multiplexing is the practice of pooling user connections through a middle tier application, so that the database sees a small number of application service accounts rather than the full user population. Oracle's licence definition explicitly covers multiplexing. The named user count includes every individual user who accesses the application that connects to the database, regardless of whether the user has a direct database account. The middle tier does not insulate the customer from the per user count.

The multiplexing question routinely produces seven figure audit findings. A customer running a web application that serves 10,000 employees through a pool of 20 database service accounts has a licensable count of 10,000 users, not 20. Oracle's audit position is firm on this point. The buyer side defence is twofold. First, ensure that the contract precisely defines who counts as a user, with multiplexing language reviewed at signature. Second, design the application architecture to minimise the population of authorised users where possible, including the use of guest accounts and unauthenticated access patterns where the data model supports them. Contract review covers the contract level defences.

Non human device counting

Non human devices that connect to Oracle Database count as named users. The category includes monitoring agents, batch processes, scheduled jobs, replication endpoints, ETL processes, integration platforms, message queues, and any other automated process that authenticates to the database. Customers commonly miss these counts because the devices are not visible in the user roster.

The audit script captures device connections through the connection history views. A monitoring tool that polls the database every five minutes from a single service account generates a connection record. The single service account counts as a named user. A monitoring tool that polls from five regional endpoints counts as five. An integration platform that connects from a load balanced pool counts as one per pool member. The deployment inventory at audit prep stage must document every device that connects, with the count and the licensing rationale.

The Enterprise application named user

Oracle E-Business Suite, JD Edwards, PeopleSoft, and Siebel are commonly licensed on application user metrics that are distinct from the Database named user plus. Customers commonly assume that the application user licence covers the underlying database user. The assumption is incorrect. The database that supports the Oracle application requires its own database licence on its own metric. The application user licence covers the application access. The database licence covers the database access. Both are required.

The pattern produces double counting findings in audits. A customer with 5,000 EBS application users running on a database supported by 50 cores has both an EBS application user count and a separate database licence count. The two are negotiated separately, audited separately, and renewed separately. Oracle E-Business Suite covers the EBS specific dynamic. PeopleSoft covers the PeopleSoft equivalent.

The right number versus the audit number

The named user plus count Oracle proposes in an audit is rarely the correct count. The audit script captures historical connection events, including one off test accounts, decommissioned monitoring tools, archived integration endpoints, and accounts that were created for a project that ended two years ago. Oracle's first pass count includes all of them. The buyer side rework filters the count to the actual current authorised population, plus the minimum requirement.

The rework typically reduces the audit count by 20 to 50 percent, depending on the maturity of the customer's user management practices. The reduction is achieved through documentation. Each removed user must be supported by evidence that the user is decommissioned, that the account is disabled, or that the device no longer connects. The evidence is normally available in the customer's identity management system, in the database security logs, and in the network access controls. Audit defense includes the user count rework as part of the engagement.

The contractual definition matters

The named user plus definition in the customer's contract may differ from the standard licence definition. Older contracts sometimes contain custom definitions that exclude non human devices, or that count multiplexing differently, or that establish more favourable minimum requirements. The first step in any named user plus audit response is to read the contract closely, identify the applicable definitions, and apply the contractual definition rather than the standard definition.

The buyer side response in audit is always to refer Oracle to the contractual definition rather than to the standard licence definitions document. If the contract is silent on a specific scenario, the licence definitions document fills the gap. If the contract is explicit, the contract controls. New ULAs and large new licence purchases are the right time to negotiate favourable named user definitions, particularly around multiplexing and device counting. Contract terms covers the negotiation points. For the broader framework download The Audit Defense Handbook.