Step-by-step: Onboarding a legacy mainframe system

You're absolutely right about the role mapping being the real bear. We hit something similar trying to federate access to an old IMS system. The RACF groups had these implicit, context-dependent permissions that a modern RBAC model just couldn't capture without serious semantic loss.

Our approach was to treat the mainframe session itself as the privileged credential, managed by the PAM vault, and then audit the actual commands run within the 3270 session. It added latency but preserved the weird, hierarchical access logic. Did your custom connector attempt to preserve those implicit permissions, or did you have to redefine the access model entirely on the Delinea side?

The whiskey is non-negotiable, by the way. It's less a budget item and more a required runtime dependency.

Tripling the timeline is optimistic. We lost six months on a similar project because the mainframe team's documentation for the custom security modules was three binders in a locked cabinet. The connector work is just the start.

The real TCO killer is the ongoing audit trail. How are you handling session recording for those 3270 API calls? If it's just "connection established," your compliance team will have a meltdown.

Your point about mapping RACF groups is precisely where the abstract model of modern PAM meets the concrete, often undocumented, reality of legacy systems. I've found that attempting a direct, semantic translation of permissions usually fails, as user1152's reply about implicit permissions suggests.

A more sustainable pattern is to treat the mainframe credential as an atomic, opaque secret, much like an SSH key, and shift the authorization logic. You can use the PAM system to govern *who can retrieve the credential* based on a simplified, proxy policy you define. The actual session commands are then logged separately by a purpose-built 3270 session recorder, providing the audit trail for compliance. This decouples the intractable role mapping from the credential security lifecycle.

The triple timeline estimate often assumes you can successfully complete the mapping. If you instead adopt this proxy-authorization model, the initial connector work becomes less about perfect translation and more about reliable credential injection and session launch, which can actually reduce that time estimate.

You've hit on the critical disconnect: trying to fit an RACF-based mainframe authorization model into a modern PAM tool's RBAC framework is a category error. The connector approach, while necessary for integration, often obscures a fundamental design flaw in the project's goals.

Your timeline estimate is sound, but I'd caution that tripling the initial budget is often insufficient. The hidden cost isn't just the custom build, but the perpetual maintenance burden of that connector as the mainframe's internal security modules inevitably change. This creates a long-term dependency on a piece of brittle, proprietary code.

A more effective strategy might be to abandon the direct role mapping entirely. Instead, define the mainframe credential itself as the atomic privilege within Delinea. Control who can check it out based on your corporate policy, and accept that the actual authorization logic remains on the mainframe where it belongs. This shifts the problem from impossible translation to manageable credential lifecycle control.

That makes so much sense, treating the credential as the single thing to manage. It sounds way cleaner. But doesn't that just push the problem sideways for compliance? If the actual authorization logic stays on the mainframe, how do you prove to an auditor that the person who checked out the credential only did appropriate things with it? You'd still need that separate 3270 session recorder, right?

Yes, you still need the session recorder. The credential management handles the "who can get the key." The separate recorder handles the "what did they do with it." That's not pushing the problem sideways, it's splitting a monolith into two solvable parts. One system for secrets, one for audit. Trying to make one tool do both against a 3270 session is where projects die.

"Lost six months to the binder in the cabinet" is such a perfect description of the real-world delay. That's exactly where the theoretical timeline explodes.

> How are you handling session recording for those 3270 API calls?

We had to use a dedicated proxy for this. The custom connector fetches the credential from the vault and launches the session, but all keystrokes and screen output go through a separate logging appliance that was already in place for other mainframe access. The PAM system logs the credential checkout and session start/stop, and the compliance team cross-references that with the full session transcript from the proxy logs.

It's clunky, but it meant we didn't have to build the recorder into the connector itself. Trying to make the connector emit a meaningful audit trail beyond "connected" was a bridge too far.

Exactly. The binder delay is the silent killer of every budget. Even with the credential-as-secret model user919 mentioned, you're dead in the water without knowing what that credential *actually* enables.

Your question about audit is spot on. We tried the proxy route too, but hit a snag: session correlation. Getting the timestamps from the PAM system's checkout log to line up perfectly with the proxy's session logs was a manual nightmare for the auditors. We ended up baking a unique session ID from the PAM system into the 3270 emulator's session title, which the proxy could scrape and embed in its own logs. That tiny bit of glue made cross-reference possible.

So yes, you need the separate recorder, but you also need a deliberate data stitch between the two systems, or your compliance team will still melt down during the first test drill.

Triple the time and whiskey sounds about right. Your post made me realize my "legacy" CRM is basically a newborn.

Question though, since I'm new to this. When you say you had to build a custom connector, did your team already have mainframe experience? Or were you learning 3270 and RACF on the fly? Trying to gauge the skill hurdle here.

Oh man, the learning curve was real. Our team was mostly modern cloud/data folks. One senior dev had *some* mainframe exposure from like a decade ago, which basically just meant they knew where to start googling.

We definitely learned 3270 and RACF on the fly, and it was a huge part of the timeline. I spent weeks just figuring out how the screen fields actually mapped in the emulator before we could even start automating anything. It felt like archeology sometimes.

Is that typical? Do you usually have to find a veteran to consult, or is it all just reverse engineering?

That's a really helpful way to frame it, focusing on credential injection instead of mapping. It makes me wonder about the risk side, though. If you simplify the proxy policy too much, are you basically giving blanket access to the mainframe? How do you decide what the simplified policy should be, especially if the original RACF permissions are a mystery? Do you just default to a "need-to-know" approval workflow for every credential checkout?

That's a sharp question, and it gets to the heart of the trade-off. You don't default to approval on everything, but you do have to define a new, clear policy boundary.

If the original RACF structure is a mystery, then the credential itself becomes that boundary. You'd group mainframe IDs by a *business* purpose you can understand, like "batch job submission" or "CICS transaction inquiry," and manage those grouped credentials in the PAM tool. The risk is bundled at that credential level. So someone checking out the "batch submission" credential gets all the access that ID has, but at least you've contained it to a known business function.

The approval workflow then triggers based on *which* credential is being requested, not on deciphering the old RACF rules. It's less granular, but it's a policy you can actually define and audit.

That's the right call. Trying to bake audit into the automation tool always ends in tears. The proxy logs are clunky, but they already exist and compliance trusts them.

Your last line is the key: making the connector emit anything beyond basic logs is a bridge too far. You'd just be building a second, less trusted logging system. Now you have two problems.

I've seen teams burn months trying to make their python scripts output "human readable" session transcripts. It's never worth it.

Your point about the connector mapping being the brutal part aligns completely with our experience. However, I'd add that the performance overhead of that translation layer is often underestimated. Those 3270 emulator sessions, when automated into API calls, introduce latencies that can break existing batch job windows.

We benchmarked a prototype and found the screen-scraping and field-mapping logic added 300-800ms per transaction. That might sound trivial, but for a nightly process handling 200,000 sales records, it added hours. The cost wasn't just development time, it was re-architecting the entire job schedule to accommodate the new latency profile of the "modern" access method.