What Is Single Sign-On and Why Does It Matter for IBM i? 

Single sign-on (SSO) allows users to authenticate once, at workstation login, and then access multiple systems without being prompted for credentials again.

For IBM i shops, this means users can connect to 5250 sessions, mapped drives, web applications, and other IBM i services using the same credentials they used to log in to their Windows PC, with no additional prompts.

IBM i has supported SSO integration with Active Directory for a long time (V5R4 and later). Despite the fact that it's a mature capability, many shops haven't implemented it.

This guide, based on a session at COMMON POWERUp 2026 by CloudFirst Senior Systems Engineer Nathan Williams, walks through how it works, what you need, and how to set it up.

The Two Core Technologies for Single Sign-On: NAS and EIM

IBM i achieves SSO through two components working in tandem:

Network Authentication Service (NAS) makes IBM i domain-aware. It enables the system to participate in Kerberos authentication, the same protocol that Active Directory uses to handle Windows logins. NAS is what allows IBM i to receive and validate Kerberos tickets from domain users.

Enterprise Identity Mapping (EIM) handles the translation step. Once IBM i knows a user's domain identity via Kerberos, EIM maps that domain identity to the correct IBM i user profile. All object authority on the system still derives from the IBM i user profile; Active Directory handles authentication, not authorization.

How the SSO Authentication Flow Works on IBM i

When a user logs in to their Windows workstation, the PC authenticates to the domain controller and receives a Kerberos ticket-granting ticket (TGT). No credentials are transmitted in plain text, which is one of Kerberos's core security advantages.

When that user then connects to IBM i, their workstation presents the TGT to the domain controller and requests a service ticket specifically for the IBM i system. The IBM i receives that service ticket, validates it through NAS, and identifies the domain user.

EIM then resolves that domain identity to an IBM i user profile, and access is granted based on that profile's authorities, exactly as it would be with a traditional password-based login.

The difference is that no password was typed, transmitted, or verified by IBM i itself.

Why Implement SSO on IBM i?

The benefits extend beyond user convenience.

Improved security: Kerberos does not transmit credentials over the wire. By contrast, unencrypted 5250 telnet sessions send usernames and passwords in plain text, something that becomes immediately obvious if you capture the traffic in Wireshark. SSO eliminates this exposure for participating users.

Password elimination: Users who only access IBM i through SSO-enabled interfaces can have their IBM i password set to *NONE. A password that doesn't exist can't be compromised. Their access becomes entirely dependent on their domain credentials, which are centrally managed.

Reduced administrative overhead: Users can't forget an IBM i password they don't have. Help desk calls for IBM i password resets don't happen for SSO-enabled accounts. Credential sharing, where users log in as someone else because that person has access to something they need, becomes effectively impossible, since SSO ties IBM i access to the individual's domain login.

Solved NetServer collisions: One of the most common and frustrating IBM i problems is users getting locked out when accessing IFS file shares through NetServer. This happens because Windows automatically attempts to authenticate using domain credentials, IBM i sees a username it recognizes but a password it doesn't, and the account gets locked. SSO is the actual solution to this problem, not a workaround.

EIM identifier maintenance reduction: Setup happens when someone joins the organization, and cleanup happens when they leave. It's not ongoing work.

Limitations to Understand Before You Start

SSO participation has some structural constraints.

First, users without a domain account cannot use SSO. Neither can users connecting from a workstation that isn't joined to the domain.

Second, a source identity (Active Directory account) can only map to one target IBM i profile. Users who have multiple IBM i profiles (test accounts, elevated-privilege accounts, etc.) can use SSO for one of them and must authenticate traditionally for the others.

Additionally, third-party 5250 clients, thick client applications, and custom-built tools may or may not support EIM. For third-party software, this is a vendor conversation. For in-house applications, developers will need to call the EIM APIs to handle the mapping themselves.

Finally, SSO creates a dependency on domain infrastructure. If the domain controller is unavailable, Kerberos authentication cannot complete, even for users who are already logged in to their workstations.

A mixed environment (some users on SSO, others on traditional authentication) is common and fully supported.

What You Need Before Starting with SSO on IBM i

Infrastructure requirements:

  • A network with a Kerberos domain (almost always Windows Active Directory)
  • IBM i at V5R4 or later
  • IBM i licensed programs: Host Servers, QShell, and Network Authentication Enablement (NAE)
  • IBM i Access Client Solutions (ACS) and Navigator for i on the IBM i system
  • Accurate, consistent DNS — both forward A records and reverse PTR records — with results that match the IBM i system's TCP/IP hostname configuration (CFGTCP option 12)
  • System time synchronized with the domain (use the domain controller as an NTP source)

Administrative requirements:

  • A user profile with *SECADM, *ALLOBJ, and *IOSYSCFG special authorities for the configuration steps
  • Cooperation from a domain administrator who understands what you're doing and has bandwidth to assist
  • A list of domain users matched to their corresponding IBM i user profiles
  • The fully qualified domain names of your domain controllers
  • The administrator password for the IBM i Directory Server (LDAP), or the ability to reset it if it's never been used

An important caution on the Directory Server: If the Directory Server is already in use by another application on your system, resetting the administrator password may break that existing configuration. Try to find the existing password before resetting it. EIM will coexist with whatever else is using the Directory Server. You just need to be able to get in to configure it.

Step-By-Step Guide to Setting Up Single Sign-On for IBM i

Step 1: Configure Network Authentication Service

In Navigator for i, navigate to Security → Network Authentication Service → Configuration Wizard.

The wizard will walk you through the following:

Default realm: This should match your Active Directory domain name, which is the portion before the backslash when users log in to Windows. Multiple domains can be added sequentially if your organization spans more than one.

KDC and password servers: In an Active Directory environment, these are your domain controllers. You can add multiple domain controllers for redundancy since the wizard lets you list more than one.

Key tab entries: This screen lists the IBM i services you want to enable for SSO. At minimum, select Kerberos Authentication (the login service) and NetServer if you're addressing the file share lockout problem. Be selective here, as every service you check creates a service account that will need to be set up in Active Directory.

Unchecked services won't be configured, and leaving unnecessary services out reduces your attack surface.

Service account password: The wizard will prompt you to set a password for the service accounts it's about to create. This password must meet your Active Directory domain's complexity requirements.

Note that a single password is set for all checked services in this pass. If your policy requires different passwords per account, uncheck all but one, complete the wizard, and then add additional key tab entries individually.

Batch file for Active Directory: The wizard will offer to generate a Windows batch file containing the commands needed to create the corresponding service accounts in Active Directory. Accept this. The file will be placed in the IFS and contains everything your domain administrator needs to create the accounts, map service principals, and configure the accounts correctly.

Your domain admin is not obligated to run the file blindly. It's a text file and can be reviewed and executed command by command, or the commands can be modified to place accounts in a different OU if their standards require it.

Give the batch file to your domain administrator. After they've created the accounts, verify the configuration from QShell by listing key tab entries (klist -k) and testing that the expected entry exists and resolves without error.

Required Active Directory account settings (your domain admin should verify these):

  • Password set to never expire: SSO will stop working for all users when service account passwords expire
  • DES encryption option unchecked
  • Delegation settings: "Trust for delegation to any service" is the simplest configuration; alternatively, the admin can configure delegation for specific IBM i services

Step 2: Configure Enterprise Identity Mapping

In Navigator for i, navigate to Security → Enterprise Identity Mapping → Domain Management → Configuration Wizard.

If NAS is already configured (which it is, from Step 1), bypass the NAS configuration prompt in the EIM wizard.

Enter the Directory Server administrator password when prompted. Create a new EIM domain. The name is effectively arbitrary, and the default works fine for most environments.

Registries: The wizard will present the registries to include. Select your Active Directory/Kerberos domain (the source) and the local IBM i system (the target). These represent the two sides of the identity mapping.

System user for EIM operations: When IBM i needs to interact with the Directory Server to perform EIM functions (such as when a user connects and the system needs to resolve their identity), it uses a designated account. The administrator account is the simplest choice for most environments.

Once the wizard completes, the system is technically enabled for SSO. Users still won't experience any change until their client is configured and their identity is mapped.

Step 3: Create EIM Identifiers and Associations

In Navigator for i, navigate to Security → Enterprise Identity Mapping → Domain Management → [your EIM domain] → Open Identifiers.

An identifier represents a person. It's a container that holds associations linking that person's various identities across systems. Identifiers must be unique, and using the person's full name (first, middle initial, last) is the most common approach.

Each identifier needs at minimum two associations:

  • A source association linking to the person's Active Directory username in the Kerberos registry
  • A target association linking to their IBM i user profile in the local IBM i registry

The usernames on each side do not need to match. A user who is w.koopa in Active Directory can map to WENDY on IBM i without any issue.

Many-to-one mappings (multiple source identities mapping to the same IBM i profile) are valid and supported. One-to-many mappings (one source identity mapping to multiple IBM i profiles on the same system) are not supported through standard IBM i Access Client Solutions. Users with multiple profiles will need to choose one for SSO and use traditional authentication for the rest.

For large environments, creating identifiers and associations manually is impractical. This process can be scripted, though you'll need three pieces of data per user: their name (for the identifier), their Active Directory username, and their IBM i user profile.

Your domain administrator can export the AD user list; the IBM i user profile list can be generated with DSPUSRPRF to an outfile. The matching step requires human judgment, since the AD list may encompass the entire organization while the IBM i list is a subset.

Step 4: Configure the Client

IBM i Access Client Solutions (ACS): In the system configuration, open the Connection tab and change the sign-on setting from the default prompt behavior to Use Kerberos/Do not prompt. The ODBC driver included with ACS picks this up automatically; if not, use the Copy Connection function in ACS to propagate the setting.

NetServer/mapped drives: Windows handles this automatically once EIM mappings are in place. Windows Explorer attempts SSO by default for every network connection. If users have IBM i credentials stored in Windows Credential Manager (often the workaround for the lockout problem), those stored credentials will need to be deleted before SSO takes effect.

Web browsers: Browsers require configuration to recognize IBM i as a trusted intranet site and send domain credentials to it. The method depends on the browser and your organization's standards; this can often be pushed via Group Policy. Note that browser configuration only gets the Kerberos ticket to the server. The web application running on IBM i still needs to be written or configured to accept and process it.

Common Troubleshooting Starting Points

Most SSO problems trace back to one of three areas.

DNS: Forward and reverse DNS records must be consistent and must match the IBM i system's configured hostname. Inconsistencies, including having multiple DNS servers where one is returning different results than the others, will cause intermittent, difficult-to-diagnose authentication failures. Start here when something isn't working.

Time synchronization: Kerberos is sensitive to clock drift. IBM i should be configured to use the domain controller as an NTP server. Set QTIME synchronization and verify NTP is active. On newer Power hardware, clock drift without NTP can be more pronounced than on older systems.

The QRMTSIGN system value: If users connecting via ACS are being presented with a sign-on screen after SSO should have authenticated them, check this value. The default setting prompts users for credentials at the sign-on screen even after they've already authenticated through Kerberos. Set it to *VERIFY to eliminate the duplicate prompt.

Scaling to Multiple IBM i Systems

One IBM i system can serve as the central Directory Server for multiple systems. Each participating system must have NAS and EIM configured, but they can all point to a single system's Directory Server as the source of EIM mappings. This simplifies administration and backup. Identity mappings are maintained in one place rather than replicated across every partition.

The Directory Server also supports replication for high availability, which addresses failover concerns in environments where SSO availability is critical to operations.

Implementing SSO on IBM i is a project that requires coordination between IBM i administrators and Active Directory administrators, some upfront planning, and careful attention to DNS and time synchronization. Once in place, it delivers meaningful security improvements, eliminates a class of authentication-related support requests, and brings IBM i into the same seamless authentication experience users expect from the rest of their network environment.

Whether you need help implementing a tool like SSO, you want to harden your cybersecurity posture, or you're looking for reliable cloud hosting that improves uptime and reduces costs, CloudFirst is here for you. Get in touch today to talk to our team.