Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Oracle EBS Kerberos SSO (Windows integrated sign-in)

Integration

Oracle EBS Kerberos SSO (Windows integrated sign-in)

People signed in to a domain-joined Windows computer land on the EBS home page with no login challenge, and everyone else sees the normal form.

Request a trial
A domain-joined Windows computer opening Oracle EBS with Kerberos single sign-on and no password prompt
Windows native authentication, also called IWA or SPNEGO.

Oracle HTTP Server with the SSOGEN Web Agent sends the browser to a sign-in source, then opens EBS as the EBS user.

Two steps: run the SSOGEN tool on the web tier, then finish the sign-on setting in PeopleSoft, JD Edwards or EBS.

Anyone who cannot use it, such as a person off the office network, on a computer outside the domain or in a browser without the setting, sees the normal sign-in page and signs in with the directory password or another method your policy allows. So internal people get zero sign-on while external people get a company-branded form with their Active Directory credentials. If your security team does not want zero sign-in for EBS, leave Windows sign-in out of the policy and keep the form.

No Oracle Access Manager, Oracle Internet Directory or Oracle Unified Directory is needed. The same Kerberos setup serves PeopleSoft and JD Edwards.

How a sign-in goes

  1. A person on the office network opens https://ebs.acme.example/OA_HTML/AppsLogin.
  2. The SSOGEN Web Agent sends the browser to SSOGEN.
  3. SSOGEN asks the browser for a Kerberos ticket. The browser sends the one Windows holds.
  4. SSOGEN checks it with the keytab, finds the person in Active Directory, and sends the browser back to EBS, which opens with that person’s responsibilities.

A Windows sign-in counts as one factor, the strength of a password. If the policy requires a second factor, SSOGEN still asks for it.

What you need

  • An Active Directory connection working in SSOGEN (Active Directory and LDAP).
  • A network zone for your office networks under SSO policies > Network zones. Windows sign-in is offered only there.
  • A domain administrator, and control of browser settings on the managed computers.
  • Oracle E-Business Suite 12.2 or 12.1, and the SSOGEN integration tool for it.

The example values: domain acme.example, Kerberos realm ACME.EXAMPLE, SSOGEN at sso.acme.example, service account svc-ssogen.

In Active Directory and the browsers

  1. Create a user account used only for SSOGEN, with a long random password. It must support AES encryption (RC4 and DES keys are not accepted), must not be trusted for delegation and must hold no other service principal names.

  2. Register the name people type for SSOGEN, without a port:

    setspn -S HTTP/sso.acme.example svc-ssogen
    setspn -Q HTTP/sso.acme.example

    The second command must show exactly one account.

  3. Export the keytab, and delete your copy after uploading it:

    ktpass -out ssogen.keytab -princ HTTP/sso.acme.example@ACME.EXAMPLE -mapuser ACME\svc-ssogen -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass *

  4. Keep clocks within five minutes of each other: the computers and the SSOGEN server.

  5. Tell the browsers to send tickets to SSOGEN. For Google Chrome and Microsoft Edge set the policy AuthServerAllowlist to sso.acme.example. For Firefox add sso.acme.example to network.negotiate-auth.trusted-uris. Do not set a delegation allowlist.

  6. Behind a load balancer or reverse proxy, allow large request headers and do not log the authorization header.

In SSOGEN

Open SSO policies > Identity providers, Add identity provider, choose Windows sign-in (Kerberos), and fill in the six steps: the name, the host name sso.acme.example and realm ACME.EXAMPLE, the keytab upload, the realm row with its directory, and the network zones.

Validate, then try the connection on a domain-joined computer, and activate.

Add Windows sign-in to the first factors of the policy that covers EBS, together with the directory so people out of the office can use their password. Every field and the error messages are on Kerberos: integrated Windows sign-in.

On the EBS side

  1. Register EBS in SSOGEN as a Web Agent application with the Client URL https://ebs.acme.example. Set Identify the person by to the value that equals the EBS user name. For John Doe the Windows logon name jdoe gives JDOE; the agent sends it in capitals and never cuts off a domain part, so a user principal name would not match an EBS user named JDOE.
  2. Run the tool and finish the setting in EBS as on the Oracle EBS single sign-on page.
  3. Create the EBS users, and keep https://ebs.acme.example/OA_HTML/AppsLocalLogin.jsp for SYSADMIN.

If it does not work

Symptom What to do
The normal sign-in page appears, with no message No ticket was offered, the computer is not on a listed network zone, the connection is not active, or the policy does not list it.
“Your browser didn’t offer a Windows sign-in” The browser is not set up to send tickets to SSOGEN, or the computer is not in the domain.
“Your Windows account isn’t set up for SSOGEN” No account, or more than one, matches in the realm’s directory. Check the user principal name and the realm row.
“Windows sign-in isn’t working on this site right now” The name is registered on two accounts, the keytab is out of date after a password change, or a clock is more than five minutes off. Export a new keytab and upload it.
Only some people fail Their tickets are large and a proxy cut the header, or the account is a service or machine account.
Sign-in works, EBS does not know the user The name sent is not an EBS user name. Change Identify the person by.

After a failed attempt, and after signing out, SSOGEN does not try Windows sign-in again in that browser for twelve hours; the person can still choose Windows sign-in from the list.

Active Directory and LDAP, AD FS (which can also do integrated sign-in), multi-factor.