It's NOT VMware/vCenter 7 (and 8) NOT 6 as 6 is EOL.

There was a bugfix to add entryUUID to the regular tree so not sure how the compat tree which was supposed to support the WIDER standard than the biz standard got left out of that.

Sorry.  It IS VMware/vCenter 7 NOT 6.  And we expect to move to vCenter/VMware 8 at some point either late this year or early next year.

IMO this would be a LOT easier if ther just was a "ID Management" entitlement like you made the "Smart Management" entitlement for Sat6.  Then I can choose between RHDS, RHCS, and IDM.  Plus that also finally provides a MONETARY stream to IDM and allows you to integrate all 3 tools together is the best way that makes the most sense (and maybe add in FreeRadius project too!).

PLUS then FINALLY there really will be NO NEED AT ALL for ad just for central auth for things like Dell DP4400, Dell Amamar, HP iLOs, Dell DRACS (which work 100% OOB with IDM 8.6+), Dell OME (works 100% 8.6+), etc.

We can NOT afford not the extra cost of AD and CALs but also WHY would we when our ESXi systems are licenses for UNLIMITED RHEL????  I am betting that I am NOT the only one in this situation!!!

Also on a side note why have the broader standard (as opposed to the BIS std) as a single plug-in.  Why not have only the main tree and just allow one plug-in that extends the schema to add whatever classed the user wants?

(Although if RH adds the "ID Management" entitlement this becomes a moot point as FreeIPA can be integrated with RHDS and RHCS so you have the full standard and access to deploy ALL tools needed from the start.)

Team, 

Please update on this request. Please share your outlook with Steve regarding what we will support for this requested feature.

Team, 

Please update on this request. Please share your outlook with Steve regarding what we will support for this requested feature.

As per the following VMware DOC:

https://kb.vmware.com/s/article/2064977

Currently, vCenter Single Sign-On supports the use of OpenLDAP as an identity source only if it satisfies all of these requirements:
The OpenLDAP schema is RFC4519 compliant.
All users have an objectClass of inetOrgPerson.
All groups have an objectClass of groupOfUniqueNames.
All groups have a group membership attribute of uniqueMember.
All users and group objects have entryUUID configured (The objects have a unique GUID and should not be changing)


To solve this (and possibly many other issues I would need this fix:   https://access.redhat.com/solutions/6167492

made in the COMPAT tree so I can try to use the compat tree as opposed to the regular tree.

VMware tech support looked at the regular tree and made these note:

================================================
Issues identified were:
- You must specifically enable the entryUUID attribute, per the following RedHat article:
    https://access.redhat.com/solutions/6167492
-  Here's how the RedHat IDM stacked up against the the requirements for an OpenLDAP Identity Source for vCenter (https://kb.vmware.com/s/article/2064977):
    A. All users have an objectClass of inetOrgPerson – Compliant
    B. All groups have an objectClass of groupOfUniqueNames – Not Compliant
    C. All groups have a group membership attribute of uniqueMember – Not Compliant
    D. All users and group objects have entryUUID configured – Compliant (after performing steps in above-linked RedHat article)
- When configuring the Identity Source, you must provide the DN of a FreeIPA user who is a member of the FreeIPA admins group, because only members of this group can read the entryUUID attribute of the FreeIPA user accounts

- Failure to do this will result in not being able to add FreeIPA users to SSO groups (you’ll see “Not allowed: <user>@<domain>’s objectId is null” in the ssoAdminServer.log)

- As the FreeIPA groups lack the required attributes, they're not searchable to add to SSO Groups, or to assign permissions to them to inventory objects
- Configuring the FreeIPA server using LDAPS was as simple as specifying the embedded FreeIPA Certificate Authority (located at /etc/ipa/ca.crt on the FreeIPA server)

In summary:
- You can configure it
- You can assign LDAP users to SSO groups
- Those users can inherit permissions based on SSO group membership
- There are still limitations because FreeIPA still does not adhere 100% to our documented requirements for an “OpenLDAP” Identity Source

Until such time as RedHat makes changes to FreeIPA to be 100% conformal to our requirements (per points B and C above), you will continue to experience problems when using it as an Identity Source.  There is no way to modify the behavior of vCenter with respect to this function.  Please let us know if you have any questions.
================================================

and I was told that the COMPAT tree DOES have groupOfUniqueNames and uniqueMember but does NOT have the entryUUID fix which it will not work at all without.

We are not considering adding official support for VSphere's limited LDAP client choices. In our opinion, VSphere as an LDAP client is in a better position to make their support of LDAP schemas more flexible.

LDAP server side has to make choices and RHEL IdM choice was made ~15 years ago to support groupOfNames/member combination, to align with other LDAP uses in POSIX world.

RHEL IdM is not an OpenLDAP server. It implements own LDAP schema which is also RFC 4519 compliant with regards to member information.

We do not use groupOfUniqueNames and do not plan to, same for uniqueMember. They do not fulfill requirements of RHEL IdM DIT and schema for the needs of RHEL IdM and we changed in favor of 'member' attribute early enough in 2007.

It comes down to a question of roles. RFC 4519 defines two methods of group management. IPA, as the server chose one. vSphere as the client chose the other, probably because whatever server they developed against used it.
As a client, you'd want to support both so you can talk to any type of server. As the server it is difficult to provide both. The proposed solution on the upstream freeipa wiki uses the compatibility tree to achieve this. This virtual view was intended to provided backwards support for RFC 2307 as a bridge for supporting legacy operating systems. That is not the case here.

VmWare has pointed to existing knowledge base that describes their requirements to existing VSphere LDAP integration. This integration is known to be very inflexible and subject to ongoing customers' complaints for decades now. For LDAP clients, it is a common approach to allow mapping internal settings to LDAP schema attributes and classes to accommodate various LDAP server implementations. This is what absolute majority of other LDAP clients do, except VMWare's software.

See, for example, https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/IILJF3YJYISDCZZ2G4NPPUO7TQV4M6RR/ which was discussed in 2020.

What about adding entryUUID to the compat tree?  You added it to the regular tree so why was it not added to the compat tree?

That is the ROOT of what this BZ is.  VMware is just one small example.  entryUUID is used by a *LOT* of things like
Dell iDRAC
Dell OME
Dell Avamar
VMware vCenter
and many more!

(HP iLO uses kerberos auth which I am STILL trying to figure out but that's a different thing all together)



*** I need to know will you add the entryUUID to the compat tree.  That is what I really need and no more. ***

All user and group accounts as well as lots of other objects in IPA have a "ipaUniqueID" attribute. IPA assigns the UUID to entries, whenever it creates a new entry. Further more, 389-DS assigns an operational attribute "nsUniqueId" to all entries, which is yet another UUID. You already have two UUIDs at your disposal.

You could map either "ipaUniqueID" or "nsUniqueId" UUIDs to "entryUUID" in compat tree. However you would have to define a new object class first. 389-DS does provide entryUUID attribute 1.3.6.1.1.16.4, but it does not provide an object class that provides the attribute.

I would rather have these LDAP clients support flexible mappings. Then they could map their "entryUUID" field to IPA's "ipaUniqueID" field and be done with it.

If you are only interested in the entryUUID from the primary tree, there is a configurational change that can bring them over.

This does not require additional object class because operational attributes allowed without a specific objectclass.

Create a file named '80-entryUUID-compat.update':

```
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
add:schema-compat-entry-attribute: entryUUID=%{entryUUID}

dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
add:schema-compat-entry-attribute: entryUUID=%{entryUUID}
```

Then apply it on each IPA server:

# ipa-ldap-updater `pwd`/80-entryUUID-compat.update
Update complete
The ipa-ldap-updater command was successful

This would insert 'entryUUID' value if it existed in the original tree for IPA users and groups.

It will not insert an entryUUID to AD users/groups. That will require additional work which we already denied.

Finally, the attribute is operational and that means it is not returned by default unless LDAP client explicitly asks for it.

Christian

Did anyone at Red Hat let Dell, VMware, etc. know about ANY of this?  I HIGHLY doubt that Red Hat even let anyone know that OpenLDAP was being dropped from my experience with vendors.  If Red Hat did let them know I doubt we would be here.

PLUS *ALL* the vendors (Dell, VMware, etc.) use entryUUID so it seems like no one got the message or RH is out of touch.  Given AD being the dominant player and IDM still trying to make some inroads I would think that is a good justification for still being compatible with the OpenLDAP that Dell, VMware and others are STILL using (again when I talk to vendors the end of OpenLDAP is NEWS TO THEM).




Alexander,

Yes as a start all I need is entryUUID in Compat as I think (or am told) 1)I should be using COMPAT for everything not SSSD based and 2) that COMPAT has the other classes/things I need not in the regular tree.
Will I need a support exception to to your solution?  I need the servers I use to have support not "best effort".  Also the tech I worked with suggested this solution:

------------------------------------------------------------------------------------------------
Most recent comment: On 2023-06-08 10:14:40, Keck, Eugene commented:
"Checking to see that entryUUID is in cn=accounts but not in cn=compat

# ldapsearch -LLLx -o ldif-wrap=no  -H ldap://rhel8.example.local -D "cn=directory manager" -w redhat12345  -b cn=users,cn=accounts,dc=example,dc=local uid=admin entryUUID
dn: uid=admin,cn=users,cn=accounts,dc=example,dc=local
entryUUID: 59e10502-799d-47cd-9cfd-c924ca842651

# ldapsearch -LLLx -o ldif-wrap=no  -H ldap://rhel8.example.local -D "cn=directory manager" -w redhat12345  -b cn=users,cn=compat,dc=example,dc=local uid=admin entryUUID
dn: uid=admin,cn=users,cn=compat,dc=example,dc=local


You would create a ldif file like the following

# cat entryUUID.ldif
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: entryUUID=%{entryUUID}


Then add it to IPA.

# ldapadd -H ldap://rhel8.example.local -D "cn=directory manager" -w redhat12345 -f entryUUID.ldif
modifying entry "cn=users,cn=Schema Compatibility,cn=plugins,cn=config"


Check to see if it worked

# ldapsearch -LLLx -o ldif-wrap=no  -H ldap://rhel8.example.local -D "cn=directory manager" -w redhat12345  -b cn=users,cn=compat,dc=example,dc=local uid=admin entryUUID
dn: uid=admin,cn=users,cn=compat,dc=example,dc=local
entryUUID: 59e10502-799d-47cd-9cfd-c924ca842651

You will need to do this on all IPA servers where you want entryUUID added to the compoat ou.

Thanks,
Eugene"
------------------------------------------------------------------------------------------------


Not sure how different each method is and if they do the same thing or not and which can be done and still consider servers I do this on as fully supported.

Eugene's method is incomplete. It is doing, essentially, the same, but only for users.

If you have needs for other vendors to support your workloads, please use your power as a customer to raise these needs with them. We keep asking VMWare customers to do so for about a decade already. We have no formal relationship with VMWare team doing this LDAP client implementation.

All,

If you can send me any links to any DOCs covering how a developer would move from OpenLDAP to IDM I'll do what I can to press it as much as I can with VMware and Dell (from ALL fronts with Sales ppl, RFEs, etc.).  

Dell is more open to change but seems to need more "help" in that they have some implementations like the DP4400 where you can't put in any groups or anything but a DNS domain and they think they can assume everything from that.  They (Dell I know at least for the DP4400 team) use java so any sample code links will help there as well.  Also any links saying basically that OpenLDAP is (as far as RH anyway) is basically dead will help as well.  All I have is just things saying that after RHEL7 it is no longer included in RHEL.

I will ask Hatem to send me things that push/promote IDM as well to include in the things I send to the vendors.


On a side note...  Curious if anyone has ever gotten an HP ILO to connect to IDM?  Those things use KERBEROS directly for logins.  :-O

BTW:  If I send you screen shots and a draft DOC for how to connect IDM to Dell iDRAC and Dell OpenManage express can you use them?  Maybe in a KB for others?

(In reply to Steven Mercurio from comment #15)
> If you can send me any links to any DOCs covering how a developer would move
> from OpenLDAP to IDM I'll do what I can to press it as much as I can with
> VMware and Dell (from ALL fronts with Sales ppl, RFEs, etc.).  

For the record, we don't want developers to move away from OpenLDAP. Our preference
are flexible LDAP clients, that can be configured to support custom LDAP schemas.
This approach avoids vendor-locking and enables LDAP clients to work with AD, IdM,
OpenLDAP with NIS or RFC2307bis schema, and others.


It's not terribly complicated to support custom LDAP schemas. An LDAP client
has to support options for

- basedn for users and groups (e.g. "cn=users,cn=accounts,dc=ipa,dc=example")
- LDAP filter for user and groups  (e.g. "(objectClass=posixAccount)")
- a mapping of internal attributes to LDAP attributes (e.g. user -> uid, username -> cn)
- an option to support RFC2307 / RFC2307bis group membership.

RFC2307 has memberUID (a list of group names) while RFC2307bis has memberOf/member
(list of group distinguished names).


Jira is a good example for a flexible LDAP client. It has profiles for most common
LDAP directories including OpenLDAP with NIS and RFC2307bis schema as well as
389-DS / RHEL-IdM (Fedora Directory Server).

https://confluence.atlassian.com/adminjiraserver/connecting-to-an-ldap-directory-938847052.html