We have nested groups living under separate organizations (o) and we reuse
groupnames like this:
cn=CO_members_all,ou=Groups,o=Foobar,dc=scz,dc=vnet
cn=CO_members_all,ou=Groups,o=Foobar2,dc=scz,dc=vnet
While importing (pull) groups from dc=scz,dc=vnet I created a template to
put groups in the realm belonging to the o the group lives under, which
works for the group under o=Foobar. The second group, which would be placed
under a different realm gets a unique naming constraint violation? How
unique do groupnames have to be in Syncope? My impression was that they
needed to be unique in a realm, not globally, but that is apparently a
misconception?
I've tried to set the naming attribute to entryDN instead of cn, but that
results in InvalidName failure, again:
Groups failed to create: CREATE FAILURE (key/name):
null/cn=CO_members_all,ou=Groups,o=Foobar2,dc=scz,dc=vnet with message:
InvalidEntityException: JPAGroup [InvalidName]
Best regards,
Martin
On Tue, May 8, 2018 at 9:53 AM Martin van Es <mrva...@gmail.com> wrote:
> I see that renaming Realms isn't forbidding in console, so keeping track
of
> the o's via entryUUID and renaming Realms should be possible if only I
knew
> how to configure that?
> As soon as I replace 'Account Uid' with entryUUID in resource the second
> pull allways results in inserts, failing unique naming constraints,
instead
> of updates.
> Another question: our groups have quite awkward names, e.g.
> "CO:members:all".
> While pull'ing I get the following error:
> Groups failed to create: CREATE FAILURE (key/name): null/CO:members:all
> with message: InvalidEntityException: JPAGroup [InvalidName,
> InvalidPlainAttr]
> CREATE FAILURE (key/name): null/CO:members:all with message:
> InvalidEntityException: JPAGroup [InvalidName, InvalidPlainAttr]
> Is it the colon in the groupname? And if so, is there a simple JEXL
> expression to replace them with a valid separation character?
> Best regards,
> Martin
> On Mon, May 7, 2018 at 4:50 PM Martin van Es <mrva...@gmail.com> wrote:
> > The only minor remaining problem: 'o' moves are not detected, because
> > there's no way I can find a way to link the realm to the source's
> entryUUID?
> > The result is there is a stale oldname realm left, and a new newname
realm
> > created.
> > On Mon, May 7, 2018 at 4:25 PM Martin van Es <mrva...@gmail.com> wrote:
> > > Fixed it. Setting 'Uid Attribute' = 'o', did the trick!
> > > Thx!
> > > Best regards,
> > > Martin
> > > On Mon, May 7, 2018 at 3:45 PM Martin van Es <mrva...@gmail.com>
wrote:
> > > > Thx for the answer.
> > > > I inspected the resource-ldap-orgunit and discoverd the omission of
> the
> > > > fullpath mapping for realms, which is mapped to LDAP l attribute.
I've
> > > > added an l attribute to my organisations and mapped that to
fullpath,
> > but
> > > > then the persistence class complains about a malformed realm path:
> > > > org.apache.syncope.core.persistence.api.dao.MalformedPathException:
> The
> > > > provided realm path is malformed: Foobar
> > > > What would the correct syntax of realm path look like? I don't see
any
> > > JEXL
> > > > transformations for both fullpath or name in the
resource-ldap-orgunit
> > > > example?
> > > > Some testing reveals the above Foobar is extracted from the o=
> > attribute,
> > > > which I mapped to 'name', which very much resembles the mapping of
ou
> to
> > > > name in the resource-ldap-orgunit example.
> > > > What's wrong with that as a path?
> > > > Here's the complete logging from my test setup:
> > > > 13:36:46.230 DEBUG Enter: search(ObjectClass: __ACCOUNT__, null,
> > > >
> org.apache.syncope.core.provisioning.java.ConnectorFacadeProxy$2@aabea88
> > ,
> > > > OperationOptions:
{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > > > Method: search
> > > > 13:36:46.232 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
null,
org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@5ba5c871
> > > ,
> > > > OperationOptions:
{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > > > Method: executeQuery
> > > > 13:36:46.232 WARN Attribute __ENABLE__ of object class __ACCOUNT__
is
> > not
> > > > mapped to an LDAP attribute Method: getLdapAttribute
> > > > 13:36:46.233 DEBUG Searching in [dc=scz,dc=vnet] with filter
> > > > (&(objectClass=organization)(!(objectClass=dcObject))) and
> > SearchControls:
> > > > {returningAttributes=[l, o], scope=SUBTREE} Method: doSearch
> > > > 13:36:46.240 WARN Attribute __ENABLE__ of object class __ACCOUNT__
is
> > not
> > > > mapped to an LDAP attribute Method: getLdapAttribute
> > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> > Value=[Foobarb]},
> > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute:
> > > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l,
> Value=[/Foobara]},
> > > > Attribute: {Name=__ENABLE__, Value=
> > > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute:
> > > {Name=__NAME__,
> > > > Value=[o=Foobarb,dc=scz,dc=vnet]}} Method: handle
> > > > 13:36:46.240 DEBUG Return: true Method: handle
> > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> > Value=[Foobarb]},
> > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute:
> > > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l,
> Value=[/Foobara]},
> > > > Attribute: {Name=__ENABLE__, Value=
> > > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute:
> > > {Name=__NAME__,
> > > > Value=[o=Foobarb,dc=scz,dc=vnet]}} Method: handle
> > > > 13:36:46.240 WARN Attribute __ENABLE__ of object class __ACCOUNT__
is
> > not
> > > > mapped to an LDAP attribute Method: getLdapAttribute
> > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> > Value=[Foobar2]},
> > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > > {Name=__NAME__, Value=[o=Foobar2,dc=scz,dc=vnet]}, Attribute:
> > > > {Name=__UID__, Value=[Foobar2]}, Attribute: {Name=l,
> Value=[/Foobar2]},
> > > > Attribute: {Name=__ENABLE__, Value=
> > > > []}, Attribute: {Name=o, Value=[Foobar2]}], Name=Attribute:
> > > {Name=__NAME__,
> > > > Value=[o=Foobar2,dc=scz,dc=vnet]}} Method: handle
> > > > 13:36:46.240 DEBUG Return: true Method: handle
> > > > 13:36:46.241 DEBUG Exception: Method: handle
> > > > org.apache.syncope.core.persistence.api.dao.MalformedPathException:
> The
> > > > provided realm path is malformed: Foobarb
> > > > ...
> > > > On Mon, May 7, 2018 at 12:33 PM Francesco Chicchiriccò <
> > > ilgro...@apache.org>
> > > > wrote:
> > > > > Hi Martin,
> > > > > short answer: your Realm mapping is not correct, hence during pull
> > there
> > > > > is no way for Syncope to match the incoming data with existing
> Realms.
> > > > > You normally "fix" incomplete mappings with Pull policies, but as
> you
> > > > > already discovered, Pull policies do not apply to Realms.
> > > > > Hence, you have no choice but providing a good mapping for Realms.
> > > > > I'd suggest to take a look at how the resource-ldap-orgunit is
> > defined:
> > > > > you can check it either via
> > > > > http://syncope-vm.apache.org:9080/syncope-console/ or by
downloading
> > and
> > > > > running the standalone distribution.
> > > > > Regards.
> > > > > On 07/05/2018 11:23, Martin van Es wrote:
> > > > > > Still stuck.
> > > > > > It would be really nice if somebody could explain how to create
a
> > > REALM
> > > > > > pull policy or tell me that it's not a possibility at the
moment?
> > > > > >
> > > > > > I've created a new AnyType FOO of AnyTypeClass BaseUser, which
> gives
> > > me
> > > > the
> > > > > > possibility to choose 'name' as PLAIN ATTRIBUTES Correlation
Rule
> > > > attribute
> > > > > > in Pull Policy 'Realm' which I can apply to the REALM Resource
> that
> > > > pulls
> > > > > > in the realms, but I keep getting u_realm_name unique name
> > constraints
> > > > > > violations on all following pulls.
> > > > > >
> > > > > > Best regards,
> > > > > > Martin
> > > > > > On Thu, May 3, 2018 at 10:31 PM Martin van Es <mrva...@gmail.com
> > > wrote:
> > > > > >
> > > > > >> Ok, I'm a step further but still have problems.
> > > > > >> I encountered the same problems when pull'ing users and it
turned
> > > out I
> > > > > >> needed to create a pull policy for users and assign that to my
> > > resource
> > > > > > for
> > > > > >> update conflict and correlation rules (I'm still learning the
> > basics
> > > > > > here).
> > > > > >> Pull Update now works for users!
> > > > > >> It turns out, I can't find anything like that for REALMS? In
the
> > pull
> > > > > >> policy rule composer I can only choose USER or GROUP. When
> choosing
> > > > USER,
> > > > > > I
> > > > > >> can only match on username, but the assigned internal REALM
> > attribute
> > > > is
> > > > > >> called 'name'. For GROUPS I can choose 'name', but then the
> policy
> > > > doesn't
> > > > > >> work or apply?
> > > > > >> Also, I tried add a REALM key to AnyTypes to contain the 'name'
> > > > attribute,
> > > > > >> but that's forbidden.
> > > > > >> Best regards,
> > > > > >> Martin
> > > > > >> On Thu, May 3, 2018 at 2:12 PM Martin van Es <mrva...@gmail.com
> > > wrote:
> > > > > >>> Hi,
> > > > > >>> On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
> > > > > >>> andreapatrice...@apache.org> wrote:
> > > > > >>>>> Realms created in the root realm:
> > > > > >>>>> CREATE SUCCESS (key/name):
> > > > > >> 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
> > > > > >>>>> CREATE SUCCESS (key/name):
> > > > > >>> 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
> > > > > >>>>> CREATE SUCCESS (key/name):
> > > > > >>> b3c86117-400b-457d-8861-17400bf57d5d///Foobar3
> > > > > >>>> Please check if realm path is correctly created on Syncope.
> > > > > >>> The Foobar realm's path is /Foobar, as expected.
> > > > > >>>> [1]
> > > > http://blog.tirasa.net/syncope-basics-manage-active-directory.html
> > > > > >>> I've checked the blog and since it's intended for AD I have to
> > mold
> > > it
> > > > > >> into
> > > > > >>> LDAP only configuration a bit. Also, my realms come from
> > > organizations
> > > > > >>> instead of organizationalUnit, but I assume that doesn't
matter
> > for
> > > > the
> > > > > >>> excersice. I have done that to the best of my knowledge,
knowing
> > > that
> > > > > >>> mapping organization only wouldn't apply the
> > > (!(objectClass=dcObject))
> > > > > >>> filter, effectively resulting in one too many Realms, but I
> could
> > > live
> > > > > >> with
> > > > > >>> that. The original problem however still remains:
consecutively
> > > > pulling
> > > > > > in
> > > > > >>> the Realms results in unique key violoations.
> > > > > >>> Since I deployed Syncope from debian packages I'm not in a
> > position
> > > to
> > > > > >>> develop, compile and deploy custom pull Actions. Also, I
accept
> > the
> > > > > > Realms
> > > > > >>> being inserted in a flat hierarchy, so I don't need any
special
> > > > mapping
> > > > > > I
> > > > > >>> hope?
> > > > > >>> Best regards,
> > > > > >>> Martin
> > > > > >
> > > > > >
> > > > > >> --
> > > > > >> If 'but' was any useful, it would be a logic operator
> > > > > >
> > > > > >
> > > > > --
> > > > > Francesco Chicchiriccò
> > > > > Tirasa - Open Source Excellence
> > > > > http://www.tirasa.net/
> > > > > Member at The Apache Software Foundation
> > > > > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> > > > > http://home.apache.org/~ilgrosso/
> > > > --
> > > > If 'but' was any useful, it would be a logic operator
> > > --
> > > If 'but' was any useful, it would be a logic operator
> > --
> > If 'but' was any useful, it would be a logic operator
> --
> If 'but' was any useful, it would be a logic operator
--
If 'but' was any useful, it would be a logic operator
