SSOGEN / Oracle EBS SSO / Oracle EBS Active Directory SSO: Connect AD and Sign In

Integration

Oracle EBS Active Directory SSO: Connect AD and Sign In

Oracle EBS Active Directory SSO here means SSOGEN checks each password against your Active Directory and the Web Agent signs the person in to EBS. You need no AD FS and no separate SAML provider. This page covers the directory side.

Application
Oracle E-Business Suite 12.2
Identity source
Microsoft Active Directory
Web Agent mode
SSOGEN
SSOGEN server needed
Yes

Which SSOGEN path this is

Oracle EBS Active Directory SSO lets people sign in to EBS with their Active Directory account, or with no password at all from a domain-joined computer. SSOGEN checks the credentials against Active Directory and the Web Agent signs the person in to EBS, with no AD FS in between. SSOGEN has protected Oracle applications in production since 2016.

This path differs from the other provider pages in this section. On pages such as Okta and AD FS, the Web Agent talks SAML to a separate identity provider. Active Directory is not a SAML provider.

Active Directory path
Web Agent mode SSOGEN (SSOGENMode ssogen, the default)
Who checks the password Active Directory, over an encrypted LDAP connection, at every sign-in
What SSOGEN stores The person’s profile and groups. It does not copy passwords
Who signs the person in to EBS SSOGEN, as the identity provider, then the Web Agent
License key Not needed for an application registered in SSOGEN

SSOGEN is a complete identity provider, so it uses your directory directly. If your organization already signs people in through AD FS, use the AD FS page instead.

Prepare Active Directory

Three things to prepare:

  • A service account. Create one used only for SSOGEN lookups, for example svc-ssogen, with a long random password. Give it permission to read the users under the part of the directory you choose, and nothing more. SSOGEN looks the person up with this account, then checks their password by signing in as them.
  • An encrypted connection. SSOGEN always encrypts the connection: choose LDAPS (usually port 636) or StartTLS (usually port 389). Plain LDAP is never used. If your domain controllers support neither, fix that first. If their certificate comes from your own certificate authority, add that authority under Trusted certificates in SSOGEN.
  • A user base DN. Choose one that holds only the people who should sign in, for example OU=People,DC=acme,DC=example. A sign-in needs exactly one entry to match the user name. A base DN that covers two places where the same person exists will fail.

Connect the directory in SSOGEN

Open Identity, then Directories, and choose Add Directory. The Connect a directory wizard has seven steps: General, Connection, Credentials, User mapping, Group mapping, Test and Review and activate.

Step What to enter for Active Directory
Connection LDAPS, a directory URI such as ldaps://dc01.acme.example:636, and the user base DN
Credentials The service account’s full DN and its password. SSOGEN encrypts them and never shows them again
User mapping Username attribute: userPrincipalName if people type maria.lopez@acme.example, or sAMAccountName if they type mlopez. Mail mail, display name displayName
Group mapping Group membership attribute memberOf, Group ID attribute cn, and optionally a group base DN
Test Creates the directory as a draft. It does not serve sign-in yet

The User mapping step with userPrincipalName, mail, displayName, givenName and sn filled in

  • Group limit. SSOGEN reads at most 64 groups for one person.
  • Group names. It skips any group whose name has characters other than letters, digits, spaces, dots, underscores and hyphens, so it does not create a group called Finance (EU).
  • Use. The groups you assign to EBS in SSOGEN come from this mapping.

On the last step, select Validate, then Test, then Activate.

Try connection takes a user name and shows each step passing, or the one that failed. It does not sign anyone in. The guide to connecting Active Directory has the full field list.

Try connection for maria.lopez@acme.example with every step passing

Choose the name EBS will see

EBS must find a user whose user name equals what the Web Agent sends. The agent sends it in capitals by default. Under Identify the person by in the application’s registration, choose the value that equals the EBS user name:

If your EBS user names are Choose
The same as the SSOGEN account name, such as MLOPEZ username
The sign-in name from the directory, such as mlopez source_username
The employee number held in the directory source_subject or a mapped attribute
The email address email

Use the application’s Test to confirm that the resulting name is the EBS user name.

A person with no value for that attribute is refused. SSOGEN does not send them under a different name.

Register EBS and connect the web tier

  1. Register EBS in SSOGEN as a Web Agent application.
  2. Set the client URL to https://ebs.acme.example, launch URL https://ebs.acme.example/OA_HTML/AppsLogin.
  3. Activate it and assign people or groups.
  4. Build and configure the module on the web tier as the Web Agent guide describes.
  5. Make the EBS application ports reachable only from the web tier.

Optional: Windows sign-in without a password

People on a domain-joined computer can open EBS through SSOGEN without typing a password.

Windows holds a Kerberos ticket, the browser passes it to SSOGEN, and SSOGEN finds the person in your directory. This needs the directory connection above, plus:

  • a service account that supports AES encryption, with no delegation and no other service principal names;
  • the service name HTTP/ followed by the SSOGEN host name, registered with setspn -S, and a keytab exported with ktpass;
  • browsers set to trust the SSOGEN host, for example with the Chrome and Edge AuthServerAllowlist policy;
  • clocks within five minutes of each other.

Windows sign-in counts as single-factor, the same as a password, so a policy that requires a second factor still asks for it.

Anyone without a ticket sees the normal sign-in page. The guide to Windows desktop sign-in has the steps.

Errors the directory produces

Test shows these messages. The table explains each one.

Message Fix
The directory could not be reached Check the host name, port and any firewall: 636 for LDAPS, 389 for StartTLS
The directory refused the bind credentials The service account’s DN or password is wrong, or the account is locked or disabled
The user base DN could not be searched The base DN has a typo, or the account has no permission to read it. Copy the distinguishedName from the OU’s attribute editor
The directory’s certificate is not trusted Add the issuing authority under Trusted certificates
The directory’s certificate does not name this host Use the host name on the certificate, such as dc01.acme.example, not an IP address or alias
n entries match that attribute; a sign-in needs exactly one Narrow the base DN

If Test passes but a person is refused, the most common cause is a username attribute that does not match what they type.

For example, it is sAMAccountName but they enter an email address, or the reverse. Run Try connection with exactly what they type.

Questions

Do I need AD FS or Entra ID to use Active Directory with EBS?
No. SSOGEN checks the password against Active Directory itself. You need AD FS or Entra ID only if you want your existing SAML provider to be the sign-in service.
Does SSOGEN copy Active Directory passwords?
No. SSOGEN checks each sign-in against the directory. By default it only reads the directory, so password resets stay in Active Directory.
Can I use Windows sign-in and a password page together?
Yes. SSOGEN offers Windows sign-in on the networks you list. Anyone without a ticket gets the normal sign-in page.
Is the connection to Active Directory encrypted?
Yes, always. SSOGEN offers LDAPS and StartTLS only.

Where to go next

Your Active Directory accounts become your EBS sign-in, with no AD FS, no copied passwords and no change to EBS code.