I wanted to get helpful howto guide when I started to work on GRC integration with LDAP (Windows AD). Unfortunately, for a man with poor or no knowledge of LDAP mechanism SAP documents not helpful, especially in case of specific customer needs. This document describes how we coped with the task of LDAP integration.

The purpose of this document is to give one more example and clarify some points of other documents.

Special thank to Neeraj Manocha who helped me to resolve the group assignment issue.

Part I. Connect GRC and LDAP

In all document the very first thing you have to do is creating connection.

Creating LDAP connection is a basis part well described here.

Go to SM59 and make the following settings

Create TCP/IP Connection (T type)

Make the following settings in tcode LDAP

To catch any problems with LDAP on first steps it’s recommended to keep trace level switched on. In the example above it’s set to 2.

Then you should maintain the user you will manage LDAP.

See further how we will use this user. Note that this user have to have all authorizations for managing users and groups.

Create server where LDAP is located.

In this example base entry is set for the root node and it should be defined in this manner:

DC=3rd level domain,DC=2nd level domain,DC=1st level domain. Note that you should use no spaces between values. For example: DC=WDF,DC=SAP,DC=COM.

If you have several connectors you can set one as a default.

The next step is defining mapping fields for managing in LDAP-GRC and GRC-LDAP directions.

Mapping subnode

At first you can use proposal mapping for the mapping (click appropriate button to do this operation).

In my example all SAP user ids are kept in the ‘pager’ field, so I select it as attribute for mapping and filtering. So that it’s not obligatory to use the proposal field ‘sapUsername’ if you don’t have it in AD.

In sum, we have determined in subnode ‘mapping’ first five fields that will be used for mapping.

Synchronization subnode

As you can see in picture above we ticked two values (pager and mail) for Import (the last two columns). This setting specifies that ticked attributes are to be imported into GRC tables. Note that no export values are ticked here, because in this example GRC should not write any data to AD, however you can tick any field for export in accordance with your needs.

In sum, we have opted those fields that will be synchronized from AD to GRC (LDAP-GRC direction).

Now everything looks prepared for the first test, click on ‘Logon’ button in tcode LDAP

Now we can use some LDAP functions, for instance, searching. Click on ‘Find’ button, determine your filter command and click ‘Execute’.

Here we get the list of attribute of the user whose pager field is equal to 101DIT00037.

If you get any problem during connection or during execution of LDAP command, please look at the trace file. It’s located in ‘work’ directory and named as ‘dev_<your_LDAP_connector_name>.trc’

Part II. GRC customizing

If you are successful with with the previous customizing part go to the next step.

Make customizing in ‘Maintain Connection Settings’ point of SPRO.

Set previously maintained connector for both PROV and AUTH scenarios.

Ensure that class CL_GRAC_AD_ACCESS_MGMT_LDAP is determined for LDAP connection type.

Ensure that class CL_GRAC_AD_AUTH_MGMT_LDAP is determined for LDAP connection type.

After this go to SPRO and find ‘Maintain Connectors and Connection Types’

Make the following settings

In sum, we have created logical group that will unite all our LDAP connectors.

Again go to SPRO and start ‘Maintain Connector Settings’

Determine the role of the connector

Select the entry and click on the subnode of the dialog structure ‘Assign attributes to the connector’

As it was in the Part I don’t use space between values. In the example above I used variables ‘User path1’, ‘User path’ since the length of the value field is limited.

So, if you have a very long path for group/user search you can divide using this variables. Let’s say, you have domain myldaporganization.ruscompany.com and you need to manage user in OU=SPB, OU=USERS and groups in OU=SPB, OU=SHAREDGROUPS for this connector.

Your setting will be looked as: USER PATH1 – DC=MYLDAPORGANIZATION,DC=RUSCOMPANY,DC=COM ; USER PATH – OU=USERS,OU=SP

Note that values are in upper case.

‘Maintain Mapping for Actions and Connector Groups’

Here action 3 is provisioning and 4 is authorizations.

For provisioning we will use these fields.

On the left hand side there are GRC fields, on the right hand side – AD fields (letters are in upper case).

These settings are provided in the guide ‘AC10_LDAP_Config_Guide’, unfortunately, the guide doesn’t say why we use them. On SCN you can find many examples of using another parameters, but not their purpose. It’s understood that OC should mean Object Class, but it’s not clear why then GROUPMEMBER is written without this suffix.

In order to use LDAP as user data source make the following setting

SPRO – ‘Maintain Data Sources Configuration’

Don’t confuse that LDAP connector has SU01 in the last column, it’s was found on one scn thread when I was searching for a solution of user data source.

In this example, system PRD420 is used as CUA central system. So when you make search GRC first goes to LDAP, if the information is not found, the search will be carried out in CUA central system.

Similar settings may be done for the other nodes.

SPRO – ‘Maintain Provisioning Settings’

You can use global setting for LDAP connector or specific

SPRO – ‘Maintain Configuration Settings’

For further group management make settings in SPRO – ‘Maintain Project and Product Release Name’

In the Part III will be described how to use what we customized.

Best regards,

Artem Ivashkin

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

    1. Artem Ivashkin Post author

      Hello Baithi,

      Thank you for the reply!

      The mentioned note, unfortunately, didn’t helped me, because it checks only the settings in general, while I had the wrong record for ldap user (I used DOMAIN\user instead of user@domain). However, as a first step to check customizing it’s truly perfect.

      Also I save the following list of notes I used:

      1823253

      1878680

      188371

      1947157

      1978357

      2202607

      2205768

      2243812

      511141

      Regards,

      Artem

      (0) 
      1. Rakesh Ram

        Hello Artem,

        One of the best document in this grc space.

        Thanks for the contribution.

        Can give 10 stars if there is a feature.

        Regards,

        Deepak M

        (0) 
  1. Zoltan Galik

    Hello Artem,

    Your document is very good, detailed and step-by-step about configuring LDAP connector.

    Recently I was also working on a document about GRC 10.X and Active Directory.

    It is about to explain group field and parameter mapping. Now it is published, hope it helps.

    Best Regards,

    Zoltan

    (0) 
    1. Artem Ivashkin Post author

      Hello Zoltan,

      Appreciate your reply and effort for adding into Alessandro’s section of helpful documents. I tried to thank you for the very detailed document, unfortunately, it was rejected by a moderator. Though I rate your document 5 stars 🙂

      Kind Regards,

      Artem

      (0) 
  2. Mark Wilson

    Hello Artem,

    we have LDAP working and we are bring back the fields we require with the exception of the Domain name. We don’t have a single domain name as Organisation is made up of multiple domains for example <Country>.<Domain>.com and this is not stored in a single attribute in LDAP. Only in the CN.

    Our SNC name consists of the <SamAccountname>@<Country>.<Domain>.com. As this can vary from user to user do you have any idea how we can extract this data into a single attribute and map this to be used in the GRC request. We cant have a defined attribute assigned to the connector

    Regards

    Mark

     

    (0) 
  3. Artem Ivashkin Post author

    Hello Mark,

    Unfortunately, I cannot help you with the extraction and manipulation of LDAP information. But I suppose you may use a self-written program, one of our self-written service works in a similar way. Then you can get a list of attributes and opt that one which best suites you. I don’t know lenght and type restriction for field ServicePrincipalNames, but you could use it, for example. Then map it to SNC AC field if you haven’t used it yet.

    Regards,

    Artem

     

    To get a list of all available attributes you can execute the following commands from PowerShell:

    import-module activedirectory

    get-aduser -Properties * artem.ivashkin | fl *

    (0) 

Leave a Reply