Hi Jason,
For OpenDJ it is actually very easy; in the Resource configuration (2nd tab); just populate the Account Object Classes variable.
I have: top; person; organizationalPerson; inetOrgPerson and tscPerson (my auxiliary class).
You could also edit the resource xml file if you prefer the import route to update the resource:
[..]
<gen927:accountObjectClasses>top</gen927:accountObjectClasses>
<gen927:accountObjectClasses>person</gen927:accountObjectClasses>
<gen927:accountObjectClasses>organizationalPerson</gen927:accountObjectClasses>
<gen927:accountObjectClasses>inetOrgPerson</gen927:accountObjectClasses>
<gen927:accountObjectClasses>tscPerson</gen927:accountObjectClasses>
[..]
Regards,
Anton
----Original message----
>From : jeverling at bshp.edu
Date : 09/07/2015 - 14:12 (BST)
To : midpoint at lists.evolveum.com
Subject : Re: [midPoint] Active Directory and custom attributes & auxiliary objectclass
Glad it helped,
I am sorry for not fully understanding your situation, I had assumed you had already added the relationship between the user objectClass and your auxiliary objectClass. Once you add that relationship then it automatically adds all those new attributes to all users in your forest.
I actually like and prefer the way AD does this over OpenDJ and OpenLDAP, I could not find a way to do this in either of the two without manually adding the new objectClass to every user :(
JASON
On Thu, Jul 9, 2015 at 5:25 AM, Pavol Mederly <mederly at evolveum.com> wrote:
Anton,
I'm glad to hear that you've worked around the problem. I would
like to add auxiliary object class support to AD connector (MID-2439).
Something else I learned from the
examples was the use on the namespace ... this was somewhat
more murky for me before. Is there a good description of their
use in the docs?
do you mean this one?
declare namespace bshp="http://idm.test.local/xml/ns/public/testdomain";
$c:user/c:extension/bshp:eduPersonAffiliation
Well, since midPoint 3.0 we have been trying to get rid of the
need of specifying explicit namespaces. Currently they are to be
used only to resolve ambiguities, with slight exceptions (see
below).
So, the path could be written as
$user/extension/eduPersonAffiliation
as well.
However, not all places in midPoint currently allow to work with
no namespaces. E.g. <ref> element in
schemaHandling/attribute or schemaHandling/association should
contain the ri: or icfs: namespace. This will be fixed in 3.3 I
hope. See MID-2191.
And also, at many places - almost all except for legacy XPath (not
<path>!) expressions - it is no longer necessary to use
"declare namespace ..." instruction. It is sufficient to declare
the namespace in traditional XML way (xmlns:xyz="...") upstream.
So even in the above example, the bshp: could be declared directly
via xmlns:bshp="..." e.g. in the root XML element.
Best regards,
Pavol
Hi,
Jason, thank you for the samples. It confirmed that I had indeed
performed all the steps required.
This allowed me to read and write custom attributes once the
auxiliary class was added to the
user entry.
Something else I learned from the examples was the use on the
namespace ... this was somewhat
more murky for me before. Is there a good description of their
use in the docs?
One thing I did not find however, was how the auxiliary was
added to the user entry; e.g. the crux
of my problem. As Pavol suggested, most may have amended the
base objectClass, or create a
new person objectClass, and subsequently would not have the
issue.
As I am not willing to add new attributes to existing OOTB
objectClasses, I had to find a different
solution. Don't like this much either, but later discovered
OpenAM already did this in our environment,
but you can set a relationship from the user objectClass to the
auxiliary objectClass in the AD
schema. This then allows you to manage the custom attributes
without the need to explicitly add the
objectClass to the user entry. For reference, this article
describes how to do this:
https://msdn.microsoft.com/en-us/library/bb727064.aspx
Ideally I would like to see proper auxiliary support for AD as
with OpenDJ, but I can live with the
solution I have for now.
Regards,
Anton
----Original
message----
From : mederly at evolveum.com
Date : 09/07/2015 - 06:59 (BST)
To : midpoint at lists.evolveum.com
Subject : Re: [midPoint] Active Directory and custom attributes
& auxiliary objectclass
Jason, Anton,
thank you for samples & suggestions for the wiki article.
I hope I'll be able to update it soon.
Anton, have you succeeded in solving your problem? If not, how
urgent is it for you?
Pavol
Sorry, that bshpSchema was a little outdatedm
wrong display order/names
On Tue, Jul 7, 2015 at 12:11 PM,
Jason Everling <jeverling at bshp.edu>
wrote:
Yes, it is defined against account. I did
not modify anything in midPoint. All I did was
reference those attributes in an objectTemplate during
user creation and modification.
I added our files along with our AD resource
header below
schema.xml is in the root on the connector server
so c:\program files (x86)\Identity
Connectors\Connector Server\ and bshpSchema.xsd is
in midpoint.home location /schema folder.
Sampled from top, the blue is what you would need
to add then reference that in templates and resource
<objects xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:mr="http://prism.evolveum.com/xml/ns/public/matching-rule-3"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
xmlns:icfc="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/connector-schema-3"
xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
xmlns:bshp="http://idm.test.local/xml/ns/public/testdomain"
xsi:schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-3
../../infra/schema/src/main/resources/xml/ns/public/common/common-3.xsd">
<icfc:configurationProperties
xmlns:icfcad="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/ActiveDirectory.Connector/Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector"
xmlns:ex="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/ActiveDirectory.Connector/Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector">
<icfcad:DirectoryAdminName>USER</icfcad:DirectoryAdminName>
<icfcad:DirectoryAdminPassword>
<clearValue>PASSWORD</clearValue>
</icfcad:DirectoryAdminPassword>
<icfcad:ObjectClass>User</icfcad:ObjectClass>
<icfcad:Container>dc=TEST,dc=LOCAL</icfcad:Container>
<icfcad:CreateHomeDirectory>false</icfcad:CreateHomeDirectory>
<icfcad:LDAPHostName>DC1.TEST.LOCAL</icfcad:LDAPHostName>
<icfcad:SearchChildDomains>false</icfcad:SearchChildDomains>
<icfcad:DomainName>TEST.LOCAL</icfcad:DomainName>
<icfcad:SyncGlobalCatalogServer>DC1.TEST.LOCAL</icfcad:SyncGlobalCatalogServer>
<icfcad:SyncDomainController>DC1.TEST.LOCAL</icfcad:SyncDomainController>
<!--
Extend Schema (reference to file on Domain
Controller) -->
<ex:ObjectClassesExtensionFile>schema.xml</ex:ObjectClassesExtensionFile>
</icfc:configurationProperties>
Then in objectTemplate mappings or resource
mappings define each attribute
<attribute>
<ref>ri:eduPersonAffiliation</ref>
<outbound>
<source>
<path>
declare
namespace bshp="http://idm.test.local/xml/ns/public/testdomain";
$c:user/c:extension/bshp:eduPersonAffiliation
</path>
</source>
</outbound>
<inbound>
<target>
<path>
declare
namespace bshp="http://idm.test.local/xml/ns/public/testdomain";
$c:user/c:extension/bshp:eduPersonAffiliation
</path>
</target>
</inbound>
</attribute>
JASON
On Tue, Jul 7, 2015 at
9:13 AM, <midpoint at mybtinternet.com>
wrote:
Hi,
I second this ... and did the same.
Regards,
Anton
----Original
message----
From : jeverling at bshp.edu
Date : 06/07/2015 - 17:26 (BST)
To : midpoint at lists.evolveum.com
Subject : Re: [midPoint] Active
Directory and custom attributes &
auxiliary objectclass
There
is also some parts that should be
added to that wiki page,
After creating the
schema.xml and adding to your
server with the Connector Server
running you have to create an
extension file for midpoint to
match that one and place in
midpoint.home schema like these (https://github.com/Evolveum/midpoint/tree/master/samples/schema)
so that midPoint can read/write to
those new objectClass attributes.
After those are added
you have to add a new declaration
to your resource xml like so
xmlns:my="http://myself.me/schemas/whatever"
Then
after you have to use that in
each custom attribute mapping
like so
<attribute>
<ref>ri:customAttribute</ref>
<outbound> <source>
<path> declare namespace my="http://myself.me/schemas/whatever";
$c:user/c:extension/my:customAttribute
</path> </source>
</outbound>
<inbound> <target>
<path> declare namespace my="http://myself.me/schemas/whatever";
$c:user/c:extension/my:customAttribute
</path> </target>
</inbound>
</attribute>
After
you add those you can
read/write to any attribute
and also create new users with
those new attributes.
When I
first setup our AD resource it
took me a little while after
looking at the samples,
something like this I think
should also be added/mentioned
to that wiki page
JASON
On Mon, Jul
6, 2015 at 11:03 AM, Jason Everling
<jeverling at bshp.edu>
wrote:
I am using the AD
Connector with additional custom
auxiliary object classes ( I
have 4 additional classes ) and
it works fine when I create new
users in the GUI or from any
other resource and is correctly
created in AD.
My Object Classes managed
in midPoint using the
extension functionality
bshpGroup
bshpOrg
bshpPerson
eduPerson
All of the above in AD
Schema are Class Type:
Auxiliary with Parent "top"
Is this not the same?
JASON
On
Mon, Jul 6, 2015 at 9:05
AM, Pavol Mederly <mederly at evolveum.com>
wrote:
Hello Anton,
now I perhaps
understand your
situation a little
bit better. Because
what I was used to
see was that people
extended the "basic"
AD user object with
custom attributes,
without introducing
separate
objectClasses.
Neither did I; and
although I've seen
that you had
mentioned using
auxiliary object
classes, I have no
experiences with
them in Active
Directory.
I
was hoping it is
possible to
override the
objectClasses in
the schema
handling, but
can't find an
example.
If you mean
adding auxiliary
object classes, then
a sample is e.g. in
testing\story\src\test\resources\unix\resource-opendj.xml
file. However,
unfortunately, this
is a feature of new
LDAP connector. The
ActiveDirectory
connector does not
support auxiliary
object classes yet.
The
other option, I
guess, would be
to use the the
custom
schema feature
of
ObjectClassesExtensionFile,
but I have a few
questions on
this:
1) Is the
objectClass type
always Tenant?
No. The new
object class can be
anything. "Tenant"
was an object class
that was used in a
particular
customer's setting.
2)
Does this add an
objectClass in
addition of the
user class or
instead of the
user class?
In addition
to the user class.
The existing
AccountObjectClass
will be left intact.
New object class
will be seen in
midPoint as CustomsomeNameObjectClass,
if the object class
will be defined as
"someName" in the
connector.
Unfortunately, the
connector will not
recognize such a
class to be an
extension of the
AccountObjectClass
and will not apply
the standard
functionality
(written in C#) to
manage objects of
this class.
So, if you would
like to use it to
manage your users,
you would need
either
1) to implement
everything in
PowerShell, which is
quite a lot of work
(given that you
would have to
implement e.g.
exception handling,
and so on),
2) or to do some
hacking with custom
scripts, like
calling original AD
connector to do its
part of the work and
then manage specific
attributes using
PowerShell.
Neither of this
seems to me a "clean
solution".
Overall, we plan to
enhance Active
Directory connector
with some of the new
features Radovan has
recently implemented
for LDAP one.
Auxiliary object
class support is
among them. But I
cannot say when that
would be done. Maybe
you could contact
Igor Farinic for
options there.
3)
How / when are
the custom
scripts called?
Custom
scripts feature is
currently only
available in
Exchange connector,
which is a superset
of AD connector
useful mainly if you
want to manage also
Exchange objects.
(But I think nothing
precludes the use of
it in AD-only
settings; I hope it
no longer depends on
the existence of
specific Exchange
run time libraries.)
These scripts are
called before, after
and/or instead of
"main" C# code. They
can be configured
with regards to
object class and
operation. E.g. you
can define a
"Before" script for
each "Create"
operation for
"AddressBookList"
object class. Or, if
you have a custom
object class, you
have to define all
the operations as
PowerShell custom
scripts.
This is an example
of definition of a
custom script:
<?xml
version="1.0"?>
<ScriptingInfo>
<OperationInfo>
<Type>Create</Type>
<AfterMain>
<ObjectType>OfflineAddressBook</ObjectType>
<File>after-create-OAB.ps1</File>
</AfterMain>
</OperationInfo>
</ScriptingInfo>
It says that after
executing main C#
routine for Create
operation for
OfflineAddressBook
object, the
after-create-OAB.ps1
file (stored in the
ConnectorServer
directory) will be
executed.
Such a script can
expect one
parameter, called
"ctx" (context),
pointing to the
following data
structure:
public class
Context {
public
Connector
Connector { get;
set; }
public
ActiveDirectoryConfiguration
ConnectorConfiguration
{ get; set; }
public
string
OperationName {
get; set; }
public
Scripting.Position
Position { get;
set; }
public
ObjectClass
ObjectClass { get;
set; }
}
(There are specific
contexts for
individual
operations, see https://github.com/Evolveum/openicf/blob/master/connectors/dotnet/ActiveDirectoryConnector/Scripting.cs
4)
Is there
examples on how
to use the
custom schema
feature?
Well, the
documentation of
these new features
is still in its
beginnings. I'm
afraid the wiki
article I mentioned
is the only piece
available :(
Maybe someone on
this list could
provide some
examples...
Overall, the most
clean way (as I
currently see it) is
to add support for
auxiliary object
classes to the
standard AD/Exchange
connector.
Best regards,
Pavol
On 6. 7. 2015
14:51, ANTON
OPPERMAN wrote:
Thx
Pavol! That is
getting me very
close ...
Took a while to
figure out just
how to do it;
the
documentation
can be clearer;
e.g. where
the value of
ObjectClassesExtensionFile
is set and which
system it should
be stored on. I
saw a ref in the
UI that seemed
to allow for
this, but this
didn't work for
me.
I have defined
my custom schema
entries in the
AccountObjectClass
section and can
retrieve and set
values if my
auxiliary
objectClass is
present on the
user. Obviously
creating an
account with
schema extension
fails as newly
created users
will not have
the auxiliary
objectClass
(yet).
I was hoping it
is possible to
override the
objectClasses in
the schema
handling, but
can't find an
example. The
other option, I
guess, would be
to use the the
custom
schema feature
of
ObjectClassesExtensionFile,
but I have a few
questions on
this:
1) Is the
objectClass type
always Tenant?
2) Does this add
an objectClass
in addition of
the user class
or instead of
the user class?
3) How / when
are the custom
scripts called?
4) Is there
examples on how
to use the
custom schema
feature?
Thx!
Regards,
Anton
----Original
message----
From : mederly at evolveum.com
Date :
02/07/2015 -
15:17 (BST)
To : midpoint at lists.evolveum.com
Subject : Re:
[midPoint]
Active
Directory and
custom
attributes
&
auxiliary
objectclass
Hello
Anton,
the AD
connector
schema can now
be extended
via
configuration.
Please see https://wiki.evolveum.com/display/midPoint/Extending+AD+and+Exchange+Connector+Schema+HOWTO
for a simple
HOWTO.
However,
contrary to
what's written
there, I would
recommend
using the
latest
versions of
AD/Exchange
connector and
ConnId:
- Exchange
Connector:
1.4.1.20283 (https://wiki.evolveum.com/display/midPoint/Exchange+Connector)
- Connector
Server:
1.4.0.84 (https://wiki.evolveum.com/display/midPoint/.NET+Connector+Server)
Also please
note that
auxiliary
object classes
are not
supported for
AD. What you
need to do is
to extend the
basic
AccountObjectClass
(or object
class for
group/OU) with
your custom
attributes.
Best regards,
Pavol
On 2. 7. 2015
16:10, midpoint at mybtinternet.com
wrote:
Hi,
We intend
managing a
number of
different
directories
with similar
data but for
populations of
users that
must be
stored
separately. We
also have a
fairly
extensive
number of
custom
attributes
grouped in an
auxiliary
objectClass.
For OpenDJ,
I was able to
setup the
resources and
am able to
manage all the
custom
attributes;
e.g.
the
connector
allows
definition of
which classes
to use.
Now trying
to replicate
with AD and
have basic AD
provisioning
working;
however, I
don't see
similar
options for
defining
additional
objectClasses
to use. Have
looked in
Jira; all
references
suggest
modifying
objectClasses.xml
and building a
custom
instance of
the connector.
I don't see
how the custom
objectClass
is referenced.
Have I missed
something?
As for
building a
custom
instance of
the
connector; I
would prefer
not to do that
as:
1)
we could run
into issues
that are
related to our
attempt of
implementing
2) each
time there is
a new fix, we
would need to
go and
retro-fit and
rebuild
3) each
time we extend
the schema, we
need to go and
ammend and
rebuild
While I may
be able to
build a custom
instance, once
this is
handed-over to
business-as-usual,
they
most
certainly will
not have the
skills to
support this.
Is this
still the
process to
follow at this
time, or has
this changed?
If not
changed, is
there a plan
to
make the AD
adapter
configurable
ito custom
schema (like
OpenDJ)?
Time-frame?
Thx
Regards,
Anton
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
--
JASON
--
JASON
CONFIDENTIALITY NOTICE:
This e-mail together with any
attachments is proprietary and
confidential; intended for only the
recipient(s) named above and may contain
information that is privileged. You
should not retain, copy or use this
e-mail or any attachments for any
purpose, or disclose all or any part of
the contents to any person. Any views or
opinions expressed in this e-mail are
those of the author and do not represent
those of the Baptist School of Health
Professions. If you have received this
e-mail in error, or are not the named
recipient(s), you are hereby notified
that any review, dissemination,
distribution or copying of this
communication is prohibited by the
sender and to do so might constitute a
violation of the Electronic
Communications Privacy Act, 18 U.S.C.
section 2510-2521. Please immediately
notify the sender and delete this e-mail
and any attachments from your computer.
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
--
JASON
--
JASON
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and
confidential; intended for only the recipient(s) named above
and may contain information that is privileged. You should
not retain, copy or use this e-mail or any attachments for
any purpose, or disclose all or any part of the contents to
any person. Any views or opinions expressed in this e-mail
are those of the author and do not represent those of the
Baptist School of Health Professions. If you have received
this e-mail in error, or are not the named recipient(s), you
are hereby notified that any review, dissemination,
distribution or copying of this communication is prohibited
by the sender and to do so might constitute a violation of
the Electronic Communications Privacy Act, 18 U.S.C. section
2510-2521. Please immediately notify the sender and delete
this e-mail and any attachments from your computer.
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint
--
JASON
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of the Baptist School of Health Professions. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150709/2137c1fe/attachment.htm>