Minimal data model

[sygilber]

Hi,

I just realize that the role 'config_policyserver' initializes the fresh remote user registry with the legacy ISAM Standard Data Model. The role offers no parameter to force either data model to be used (Standard or Minimal) but it goes down as well to the ibmsecurity module that offers no capability to select the data model. And this goes down (as far as I know) at the rest-api level that is not making any references to the data model. I can see that my Policy Server initialized the fresh remote user registry using the legacy Standard Data Model because of the LDAP attributes found at the container level 'SECAUTHORITY=DEFAULT':

objectClass: cimLogicalElement (abstract) objectClass: cimManagedElement (abstract) objectClass: cimManagedSystemElement (abstract) objectClass: eApplicationSystem (structural) objectClass: eSystem (structural) objectClass: secAuthorityInfo (structural) objectClass: top (abstract) secAuthority: Default version: 3.0 installDate: 2018-01-19 18:16:58 EST (20180119231658.0Z)

You can see the version: 3.0.

I am unsure now where to head to resolve this. -Open a case with support ? -Or is there a solution to workaround this behavior ? -Is swithing to the Minimal Data model on a fresh empty remote user registry is simply a matter of modifying the 'version' LDAP attribute in the registry ?

Please advise.

[jldement]

The version attribute is used by ISAM to control the search logic but not the actual format of the data that is stored in the LDAP therefore simply changing the value of "version" from "3.0" to "6.0" will not work (confirmed by IBM L2 support). This seems bad but have no workaround except to use the LMI which seems to do the right thing (no time right now to reverse engineer what call(s) the LMI is using).

=================================================== Jeffrey L. DeMent IBM Security Systems | Directory & Security Architect 602.284.0100 (cell) | jdement@us.ibm.com

From: Sylvain Gilbert notifications@github.com To: IBM-Security/ibmsecurity ibmsecurity@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Date: 01/24/2018 09:40 AM Subject: [IBM-Security/ibmsecurity] Minimal data model (#55)

Hi,

I just realize that the role 'config_policyserver' initializes the fresh remote user registry with the legacy ISAM Standard Data Model. The role offers no parameter to force either data model to be used (Standard or Minimal) but it goes down as well to the ibmsecurity module that offers no capability to select the data model. And this goes down (as far as I know) at the rest-api level that is not making any references to the data model. I can see that my Policy Server initialized the fresh remote user registry using the legacy Standard Data Model because of the LDAP attributes found at the container level 'SECAUTHORITY=DEFAULT':

objectClass: cimLogicalElement (abstract) objectClass: cimManagedElement (abstract) objectClass: cimManagedSystemElement (abstract) objectClass: eApplicationSystem (structural) objectClass: eSystem (structural) objectClass: secAuthorityInfo (structural) objectClass: top (abstract) secAuthority: Default version: 3.0 installDate: 2018-01-19 18:16:58 EST (20180119231658.0Z)

You can see the version: 3.0.

I am unsure now where to head to resolve this. -Open a case with support ? -Or is there a solution to workaround this behavior ? -Is swithing to the Minimal Data model on a fresh empty remote user registry is simply a matter of modifying the 'version' LDAP attribute in the registry ?

Please advise.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sygilber]

Thanks, I never tested using the LMI to configure fresh a remote user registry. I will try that myself to see if it proposes the selection of the data model or simply defaults to using the minimal data model under the hood.

[ram-ibm]

Standard model is not longer an option. You should be seeing Minimal Model - perhaps we need more information on the LDAP options you are using? Is it the Embedded LDAP being used for the Runtime or an external LDAP? Was the LDAP server configured previously for ISAM/TAM?

[sygilber]

I am using a fresh vanilla external ldap (itds). I will test tomorow using the LMI as suggested previously in this thread.

[ram-ibm]

Hoping you can also create a test user and see if there are entries under the regular suffix (not secAuthority=Default) to confirm that you are indeed in Standard Model. Pretty sure that Standard Model is not an option anymore.

[nick-lloyd]

Hi Sylvain,

IBM Access Manager Support does not accept Cases for this framework. Support is provided via GitHub issues. Now, should the use of this framework uncover a defect in the actual REST API which gets called that of course should be handled with a Support Case.

I took a look at the role and see it is using the documented options, of which there is not an option to select data model.

Also odd is the date:

installDate: 2018-01-19 18:16:58 EST (20180119231658.0Z)

Is that what it really looks like or did you just expand for clarity? It should just be:

installDate: 0180119231658.0Z

Do you have LDAP auditing enabled? If so, we can track the exact creation and modification of the object.

Nick ISAM Level II Support

[sygilber]

Hi Nick

You just not worry about the previouly "pasted" attributes of my ITDS server. It is the LDAP browser that I am making use of that "enhanced" the date attribute. The real output (ldif export) is the following:

dn: secAuthority=default objectClass: cimManagedElement objectClass: cimManagedSystemElement objectClass: cimLogicalElement objectClass: eSystem objectClass: eApplicationSystem objectClass: secAuthorityInfo objectClass: top secAuthority: Default version: 3.0 installDate: 20180119231658.0Z

As for support related concerns, I understand all there is to know about this project. So once I share my observations with LMI/REST methods (and external LDAP), we can determine if this is a case for the IBM support group (opening a case) or if there is something we could replicate that is done in the LMI to do the trick, or just nothing to do because I would not have replicated it.

I still need to provide you all with a complete re-test of everything I have done earlier this week (with and without LMI/REST method) but I am just slowed down now by the unavailability of my environment which is down. I hope to finalize my re-testing tomorrow.

As a side note, what gave us a hint that something was wrong at first was not the "version" attribute stored in the external LDAP but the fact the under cn=users, all entries will be listed as "secUUID=" as opposed to be listed as "principaleName=", and searching a bit it turned to tell us that this match the standard data model.

We will enabling tracing in LDAP when I am ready to re-test, and create some users other than just sec_master, and the other ISAM server deamons accounts.

Sylvain

[sygilber]

Here are my observations.

Methodology: Used the same ISAM 9.0.4 appliances and the same ITDS directory server instance. Before each test run, I reverted back any VM 9.0.4 appliances to an almost factory image, and delete entries in the ITDS directory server instance.

a) test 1 (6.0)

I have used a ITDS directory server instance created with secauthority=default suffix built from our latest "build" system (preparing for minimal data model).

version: 1

dn: secAuthority=default objectClass: cimManagedElement objectClass: cimManagedSystemElement objectClass: cimLogicalElement objectClass: eSystem objectClass: eApplicationSystem objectClass: secAuthorityInfo objectClass: top secAuthority: Default version: 6.0

Running the ansible playbook, I have obtained a version=6.0 Minimal Data model directory structure.

b) test 2 (3.0)

I have used a ITDS directory server instance created with secauthority=default suffix built from a far older "build" system (preparing for standard data model).

version: 1

dn: secAuthority=default objectClass: cimManagedSystemElement objectClass: eApplicationSystem objectClass: eSystem objectClass: cimManagedElement objectClass: cimLogicalElement objectClass: secAuthorityInfo objectClass: top secAuthority: Default version: 3.0

Running the ansible playbook, I have obtained a version=3.0 Standard Data model directory structure.

The results are attached.

So I can only conclude for now the following:

1) Early in the previous weeks, when I started testing initializing the 9.04 & external ldap, I picked the wrong ITDS dit instance image before running the ansible playbooks. This is just plain old, we are not using it for a least 6 years, it was just a mistake of mine.

2) When using our up-to-date ITDS dit instance image, I obtained the proper Minimal Data model structure from running the un-modified ansible playbooks against 9.04 & external ldap.

3) 9.04 appliance code still has the ability to detect which structure is in place (object classes) and supports initializing both of data model, although it might not be encourage to use the Standard Data model. No one will want to do this I guess, but it is still in the 9.0.4 code.

4) No Case to open with support, and nothing to update/fix in the ibmsecurity python module.

I don't think I need to push this investiguation further. I will just ensure to use our proper directory server instance image when building fresh isam 9.04 environment (not migrated ones).

I least I was able to demontrates that 9.04 still understands what is Standard Data model.

I will wait 1-2 days before closing this Issue if there are any questions submitted arround my observation.

The below attached file are LDIF formatted but I had to rename the extension.

secauthority=default-test1-after-ansible.txt secauthority=default-test2-before-ansible.txt secauthority=default-test2-after-ansible.txt secauthority=default-test1-before-ansible.txt

[sygilber]

Thanks all for the help on this one.