Search Results terminal_id

Overview

FND_UNSUCCESSFUL_LOGINS is an Oracle Application Object Library (FND) table owned by the APPLSYS schema. It stores Sign-On Audit information about unsuccessful login attempts made against an Oracle E-Business Suite environment, whether through the Oracle EBS login page, Oracle Forms-based sign-on, or self-service applications. The table is available and documented in both Oracle EBS 12.1.1 and 12.2.2, and its structure has remained stable across these releases.

The table functions as an audit trail for authentication failures. Each row captures one failed attempt, recording who attempted to log in, when the attempt occurred, and from which terminal or client the attempt originated. This supports security auditing, account lockout administration, and forensic analysis of unauthorized access attempts. The Sign-On Audit feature must typically be enabled (via profile option "Sign-On Audit Level" / FND_SIGNON_AUDIT) for rows to be written, so the table may legitimately be empty in environments where that auditing is disabled.

Under a heuristic Data Vault classification derived from its foreign key structure, FND_UNSUCCESSFUL_LOGINS is satellite-leaning. It holds descriptive, time-stamped event attributes about the login attempt rather than serving as a hub of core business entities or a pure link between hubs. The USER_ID reference to FND_USER suggests it could be modeled as a satellite hanging off the FND_USER hub.

Key Information Stored

The documented physical schema in ETRM 12.2.2 consists of four columns, which together form the primary key FND_UNSUCCESSFUL_LOGINS_PK:

• USER_ID — The numeric identifier of the FND_USER account against which the failed attempt was made. This column is also a foreign key to FND_USER, enabling joins to user account details.
• ATTEMPT_TIME — The date and timestamp at which the unsuccessful login attempt occurred. This is the principal time dimension and is part of the composite primary key.
• LOGIN_NAME — The login name supplied at the time of the attempt. It is stored independently of USER_ID because a failed attempt may reference an unknown or mistyped username that does not resolve to a valid FND_USER record.
• TERMINAL_ID — The identifier of the terminal, host, or client machine from which the attempt originated, useful for identifying the source of repeated failures.

The composite primary key comprises USER_ID, ATTEMPT_TIME, LOGIN_NAME, and TERMINAL_ID. There is no separate surrogate key column; the business identity is defined by the combination of account, time, login name, and terminal. USER_ID, where populated, is the primary business-key candidate linking to the FND_USER master.

Common Use Cases and Queries

Security administrators and DBAs query this table to detect brute-force attempts, identify locked or targeted accounts, and investigate suspicious sign-on activity. A typical pattern counts failures per login name to surface concentrated attacks:

• Counting failed attempts per account: SELECT LOGIN_NAME, COUNT(*) FROM FND_UNSUCCESSFUL_LOGINS GROUP BY LOGIN_NAME ORDER BY 2 DESC;
• Filtering a time window: SELECT * FROM FND_UNSUCCESSFUL_LOGINS WHERE ATTEMPT_TIME > SYSDATE - 1;
• Joining to user details: SELECT u.USER_NAME, l.ATTEMPT_TIME, l.TERMINAL_ID FROM FND_UNSUCCESSFUL_LOGINS l, FND_USER u WHERE l.USER_ID = u.USER_ID;
• Identifying source terminals with repeated failures: SELECT TERMINAL_ID, COUNT(*) FROM FND_UNSUCCESSFUL_LOGINS GROUP BY TERMINAL_ID;

Because the table can grow large in audited environments, purge and archival jobs are typically scheduled. Reporting may be routed through the Sign-On Audit reporting screens in the System Administrator responsibility.

Related Objects

FND_UNSUCCESSFUL_LOGINS is closely tied to the sign-on and user management framework. The most significant related objects include:

• FND_USER — Joined via USER_ID; the referenced master account table for successful identities. This is the documented foreign-key relationship.
• FND_LOGINS — Companion Sign-On Audit table recording successful login sessions.
• FND_LOGIN_RESPONSIBILITIES and FND_LOGIN_RESP_FORMS — Record responsibility and form-level activity once a user is signed on.
• FND_SIGNON_AUDIT profile / Sign-On Audit feature — Controls whether rows are captured.
• ICX_SESSIONS — Self-service session tracking, complementary to sign-on auditing.

Together these objects form the FND security audit schema used for authentication and access monitoring in Oracle EBS.