On Thu, Mar 5, 2015 at 10:37 AM, Martin Kosek <mko...@redhat.com> wrote:

> >
> > users' updates were force by vSphere originated queries.
> > For example without adding iNetOrgPerson objectclass, when I wanted to
> bind
> > a permission to a user and searched for users in vSPhere, I got this
> error
> >
> > 05/Dec/2014:22:59:21 +0100] conn=1831 op=34 SRCH
> > base="cn=users,cn=compat,dc=localdomain,dc=local" scope=2
> > filter="(&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))"
> > attrs="description entryuuid givenName initials mail pwdaccountlockedtime
> > shadowExpire sn title uid userPassword"
> I see. The filter is quite strange though, I am not sure why is vSphere
> searching for the same value twice. I assume this is a (benign) bug in
> vSphere:
> (&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))
> > So I verified that adding inetOrgPerson I was then able to add users to
> > permissions.
> > Probably I have to check which are the MUST attributes for it so that we
> > add the too
> >
> > As far as I understood, the use of compat was indeed to add uniqueMember
> > that is expected to be there by vSphere, at least in 5.1
> I checked the MUST already, I updated
> http://www.freeipa.org/page/HowTo/vsphere5_integration
> and added the missing SN attribute and removed the invalid objectClass. I
> hope
> that's fine with you.
> HTH,
> Martin

OK for the SN.
But what about uniqueMember removal?
Would complete then successfully the query that is based on this
modification on compat groups:


As far as I verified, vSphere 5.1 makes this query to check if a user has a
role, as deriving from being part of a group:
ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"

and without uniqueMember, I could bind roles directly against users, but
the ones applied on groups were not inherited by the users inside the

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to