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 <[email protected]> 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ò <
[email protected]>
> 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 <[email protected]>
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 <[email protected]>
wrote:
> > >>> Hi,
> > >>> On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
> > >>> [email protected]> 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
