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
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
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
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
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
Hi,
This is related to my earlier question about creating Realms based on
dynamic VO's (organized as o= entities in LDAP).
I'm trying to get FULL RECONCILIATION working, which succeeds for the first
time, but results in unique "u_realm_name" constraint violations on second
attempt, even though I
