Your SAP GRC LDAP connector can find terminated users. Most teams never ask it.

Almost every SAP GRC Access Control implementation configures an LDAP connector at some point during the build. It gets mapped to Active Directory, tested against a handful of users, wired into the access request form so that first name, last name, email, and manager populate automatically — and then it is never touched again.

That connector can do considerably more than fill in a form. It can tell you who left the company.

Active Directory already knows

Active Directory stores account state in a single attribute: userAccountControl.

A normal, enabled user account carries the value 512. When that account is disabled, the value becomes 514. Confirm the convention with your own AD team before you build anything on it — the value is the part that matters, and estates do differ — but in most environments a disabled account is exactly what an offboarded employee leaves behind.

Your GRC system can already read that attribute. The connector is configured, the data source is mapped, and the LDAP search function module is available. Nothing new has to be licensed, installed, or bought. The only thing missing is the question.

The logic, in four steps

This is a custom ABAP program. SAP delivers the connector and the function module; it does not deliver the report. That is worth stating plainly, because most teams assume a capability like this must exist somewhere in the standard and simply hasn't been switched on. The point of writing it down is that the logic is simple enough that most teams are surprised they never built it.

1. Search Active Directory for disabled accounts

   Search Active Directory through the existing GRC LDAP connector for accounts whose userAccountControl indicates a disabled state. The connector is the transport, not the function. There is no standard SAP report or transaction that performs this comparison — after configuration, someone has to write an ABAP program that calls the LDAP search function module and does the work.

2. Reconcile each AD identity to SAP user IDs

   Reconcile each AD identity to SAP user IDs across every connected system. This is the hard step, and the rest of this article is mostly about why.

3. Compare against SAP

   For each reconciled identity, check whether the SAP user is still active and still holds role assignments. A disabled AD account against an active SAP user with live roles is your exception.

4. Raise a GRC access request per exception

   Raise a GRC access request per exception, with the AD evidence attached. GRC already exposes access request submission as a web service for identity management integration — the same interface accepts a request raised by your own program.

The output is a queue of leavers who still hold SAP access, generated on a schedule, evidenced, and already sitting in the GRC workflow — the same handoff the Access Request Management module uses for every other request.

Where it breaks: identity reconciliation

Step two is clean in a demo and rarely clean in production. Three failure modes, in the order they cause damage.

Name matching

When AD sAMAccountName and SAP user ID do not correspond, the obvious fallback is to match on first and last name. Two employees share a name, one of them leaves, and your program proposes removing access from the wrong person. This needs to happen once to end the programme's credibility with the business.

Identities with no AD counterpart

Service accounts, batch users, RFC and interface users, and legacy IDs created before the current directory existed. None of them will ever appear in a disabled-accounts list, which means none of them will ever be reviewed by this process. If you present the output as a complete leaver review, you have quietly excluded the population that most often carries excessive authorisation.

Contractors and non-employees

Frequently in a separate organisational unit, occasionally in a different forest, sometimes not in the directory at all. Their offboarding is also the least reliable, which is precisely why you wanted the check.

Automate the detection. Do not automate the decision.

It is tempting to close the loop entirely: disabled in AD, therefore lock the SAP user and strip the roles, no human involved.

Resist it, for a straightforward reason. A disabled AD account is a signal, not a decision. Long-term leave, secondment, maternity and paternity leave, suspension pending investigation, and a staged offboarding where the directory is disabled weeks before the final working day all produce exactly the same attribute value as a resignation. The filter cannot tell them apart, and neither can any amount of logic layered on top of it.

The right division is that detection, comparison, and request submission are automated, and the removal is approved by a person who can see the evidence. That is also what an auditor wants to see: a repeatable detection control with a documented human approval, not an unsupervised script with production authorisation.

What you need in place

• An LDAP connector configured in GRC and reachable from the system where the program will run. SAP's configuration reference is here.
• Read access to the userAccountControl attribute, confirmed with your AD team along with the disable convention used in your estate.
• A defensible mapping between AD identities and SAP user IDs, and an honest list of the identities that mapping does not cover.
• An agreed owner for the exception queue. A report nobody is accountable for reviewing becomes a report nobody reviews.
• ABAP development capacity, plus an owner for the program after it is built. A custom Z program is something you maintain through every AD change, every new connected system, and every upgrade.

The point

None of this is a product. It is a standard GRC connector, a standard Active Directory attribute, and logic that fits on one page. If your LDAP connector is already configured for name lookups, most of the work is behind you.

The reason it is worth doing is timing. A quarterly user access review — the kind covered in our guide to running one that actually passes audit — will eventually find the leaver who kept their SAP access. A nightly comparison finds them the following morning.

Syntasec by SyntaAI is an on-premises SAP security and compliance platform. It runs inside your network and complements SAP GRC rather than replacing it — the platform proposes findings like this one, and a human on your team approves and executes any resulting change in GRC. If leaver access is something you are working on, we are always interested in comparing notes.