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 real
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 nam
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 wrote:
> Fixed it. Se
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 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 attribut
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
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
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 attri
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 u
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 S
Hi Martin,
first of all I suggest to refer to this blog post [1] to have a
reference on how con configure (also) mapping for realm provisioning.
Il 03/05/2018 12:14, Martin van Es ha scritto:
Hi,
This is related to my earlier question about creating Realms based on
dynamic VO's (organized a
10 matches
Mail list logo
