How to Integrate Active Directory as a User Data Source in SAP® GRC

Streamline Your Governance: How to Integrate Active Directory as a User Data Source in SAP® GRC

In any organization, user identities are the cornerstone of access and governance. For companies using Microsoft Active Directory (AD) as their central identity hub, manually recreating and maintaining these users in SAP Governance, Risk, and Compliance (GRC) is a redundant, error-prone, and unsustainable task.

The solution? Direct integration. By connecting SAP GRC directly to Active Directory, you can automate user provisioning, ensure consistency, and create a single source of truth for user identities across your SAP and Microsoft landscapes.

This guide walks through the key concepts and steps to integrate AD as a user data source in SAP GRC.

Why Integrate? The Benefits of Automation

Pulling users directly from AD into GRC isn’t just a technical exercise; it’s a major efficiency win.

• Eliminate Manual Entry: Automatically create, update, and deactivate users in GRC based on their status in AD.

• Ensure Consistency: User IDs, first names, last names, and email addresses will always match between AD and GRC.

• Automate De-provisioning: When an employee leaves and their AD account is disabled, you can automatically trigger a de-provisioning workflow in GRC, instantly mitigating access risks.

• Maintain Data Integrity: Reduces the risk of typos and outdated information, leading to more accurate access requests and risk analysis.

The Core Concept: Understanding the GRC Connector Framework

SAP GRC uses a flexible Connector Framework to communicate with external systems like Active Directory. This framework uses a standard protocol called HTTP(S) with SOAP to exchange data. The key components are:

1. GRC System: The consumer of the user data.

2. Connector: A piece of software that acts as a translator between GRC and the external system. For Active Directory, this is the Microsoft Active Directory Connector.

3. External System: In this case, your Microsoft Active Directory domain.

The connector is installed on a server that has network line-of-sight to both your GRC system and your Active Directory Domain Controller.

Step-by-Step: The Integration Process

Here’s a high-level overview of the steps involved in setting up the integration.

Phase 1: Prerequisites and Planning

• Identify a Server: Provision a Windows server (physical or virtual) to host the GRC Active Directory Connector. This is often called the “Connector Server.”

• Service Account: Create a dedicated service account in AD with read-only permissions. This account should have the minimum privileges needed to query user objects (e.g., read access to the relevant Organizational Units – OUs).

• Network Access: Ensure the Connector Server can communicate with:

  • The GRC application server over HTTPS (usually port 443).

  • An Active Directory Domain Controller over LDAP (port 389) or secure LDAP (LDAPS, port 636).

• Download Software: Obtain the latest GRC Access Control Content package from the SAP Support Portal. This contains the installer for the Active Directory Connector.

Phase 2: Install and Configure the Connector

1. Run the Installer: On the Connector Server, run the setup.exe from the downloaded package and choose to install the Microsoft Active Directory Connector.

2. Configure Connection to AD: The installer will prompt you for the AD connection details:

   • Domain Controller name or IP.

   • Port (389 for LDAP, 636 for LDAPS).

   • The service account credentials you created.

   • The base Distinguished Name (DN) for the search (e.g., OU=Users,DC=mycompany,DC=com). This defines where in the AD tree the connector will look for users.

3. Configure Connection to GRC: You will also provide the details of your GRC system:

   • GRC hostname and port.

   • SOAP service endpoint.

   • A technical communication user in GRC with the required permissions (like GRACCONNECTOR).

Phase 3: Configure the Data Source in GRC Web UI

With the connector installed, you now tell GRC how to use it.

1. Log in to the GRC NWBC or Fiori launchpad with an administrator account.

2. Navigate to: Common Setup Components > Data Sources > Data Source Management (Transaction GRCSPROXY).

3. Create a New Data Source:

   • Data Source Type: Select Active Directory.

   • Technical Name: Give it a meaningful name (e.g., AD_CORP).

   • System Type: Non-SAP.

   • Connection Details: Provide the hostname and port of your Connector Server (not the AD server itself).

4. Test the Connection: Use the built-in test function to verify that GRC can communicate successfully with the connector and that the connector can talk to AD.

Phase 4: Define and Schedule a Job to Import Users

The final step is to create a job that pulls the user data.

1. Navigate to: Access Control > Administration > Import Users from Data Source (Transaction GRACI_IMPORT_USER).

2. Create a New Job:

   • Select your newly created AD data source.

   • Mapping: This is a critical step. You must map the fields from Active Directory to the corresponding user fields in GRC.

     • Map sAMAccountName to User ID.

     • Map givenName to First Name.

     • Map sn to Last Name.

     • Map mail to Email Address.

   • Filter (Optional): You can add filters to only import users from a specific AD OU or with certain attributes (e.g., (&(objectCategory=person)(objectClass=user))).

3. Schedule the Job: Set the job to run on a regular schedule (e.g., nightly). This ensures GRC user master data is always synchronized with AD.

Key Considerations and Best Practices

• LDAPS is Non-Negotiable: Always use Secure LDAP (LDAPS) to encrypt the communication between the connector and your Domain Controller. This protects sensitive user information in transit.

• Start with a Pilot OU: For your initial import, filter the job to a small, test Organizational Unit. Verify the data is correct before importing all users.

• Handle “Display Name”: AD’s displayName field is often a single string (e.g., “Doe, John”). You may need to use a custom script or a separate mapping logic to split this into GRC’s separate First Name and Last Name fields if those core attributes are not populated.

• Plan for Deletions/Deactivations: Decide on a strategy for handling users deleted in AD. Often, it’s better to deactivate them in GRC rather than delete them to maintain an audit trail.

Conclusion

Integrating Active Directory as a user source is a foundational step towards a modern, automated, and secure GRC implementation. It closes a critical gap in your identity governance process, ensuring that the users who request and hold access in your SAP environment are always reflective of the real-world employees in your organization. By eliminating manual syncs, you not only save time but also significantly strengthen your security posture.